wdiff draft-farinacci-lisp-rig-03.txt = draft-farinacci-lisp-rig-04.txt

ciao

Luigi<= /div>



Internet Engineering Task Force                             D. Farinacci
Internet-Draft                                               lispers.net
Intended status: Experimental                                    A. Jain
Expires: September 18, 2014                             Juniper Networks
                                                             I. Kouvelas
                                                                D. Lewis
                                                           cisco Systems
                                                          March 17, 2014


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

=

[snip]

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

I would put = =93distributed 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.


3.  Definition of Terms

I would put the definitions of = terms as appendix. This document is not authoritative on = these

definitions. An appendix to help reading is = enough.

Check the eid block documents as = example:

http://to= ols.ietf.org/html/draft-ietf-lisp-eid-block-09

htt= p://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-01

<= br>

   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

[snip]


Farinacci, et al.      Expires September 18, 2014               [Page 7]
=0C
Internet-Draft   LISP-DDT Referral Internet Groper (RIG)      March 2014


4.  Basic Overview

Just to ease even more the reading = wouldn=92t be helpful put how mapping lookup works in = DDT?

Something describing by text the content = of slide 7 of:

http:= //tools.ietf.org/agenda/83/slides/slides-83-lisp-8.pdf

<= /div>

 =
  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

Typo: =93A = round-trip-time=85"

      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 text above is = unclear.

If follow-all-referrals is present = then rig follows all RLOCs: that is OK.

If the = option is not present why should the rig command follow the first = RLOC?

The initial description of rig = (first paragraph section 4) just states the upon reception of a = Map-Referral,

its content is displayed to the user, it does = not mention that any RLOC is followed to go down the DDT = tree.

Why not adding a =93follow-first-referral=94= option to actually follow the first = RLOC.

Which implies as well that if no = =93follow-xxx-referral=94 option is present the simple referral reply is = displayed with no further = queries.


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

[snip]

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

Any other implementation available? = Steffann has a ddt_query script written in = python...



Farinacci, et al.      Expires September 18, 2014              [Page 10]
=0C
Internet-Draft   LISP-DDT Referral Internet Groper (RIG)      March 2014

[snip]


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.

I would add a reference to the = lisp-threats = document.

   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.



=

[snip]

8.  References

8.1.  Normative References

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

Delete this reference it is never = cited.


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

This is used in the definition of = terms section and since this document is not authoritative = on

those definitions it might be better to put the = reference as informative.


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

As far as I can see there is not = 2119 notation actually concerning rig, IMHO we can drop this = reference.


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

This is used in the definition = of terms section and since this document is not authoritative = on

those definitions it might be better to put the = reference as informative.

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

This is used in the = definition of terms section and since this document is not authoritative = on

those definitions it might be better to put the = reference as = informative.


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

What? Since RIG is a tool to debug = DDT I would expect that the DDT document is = normative.

= --Apple-Mail=_AE68E0DC-2E4D-4424-BC0E-C2E26F878B31-- From nobody Wed Jul 2 03:12:39 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D906D1B27E1; Wed, 2 Jul 2014 03:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz9JqEYaWZ9o; Wed, 2 Jul 2014 03:12:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 130971B28EC; Wed, 2 Jul 2014 03:12:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702101235.30470.80375.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 03:12:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/v79iTwxKsGkgOdZVvZ6j1KHDlfM Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-mgmnt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 10:12:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP EID Block Management Guidelines Authors : Luigi Iannone Roger Jorgensen David Conrad Filename : draft-ietf-lisp-eid-block-mgmnt-02.txt Pages : 13 Date : 2014-07-02 Abstract: This document proposes an allocation framework for the management of the LISP EID address prefix. The framework described relies on hierarchical distribution of the address space with sub-prefixes allocated on a temporary basis to requesting organizations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-block-mgmnt-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 03:20:37 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4B61B28EB for ; Wed, 2 Jul 2014 03:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMaTJEookFw4 for ; Wed, 2 Jul 2014 03:20:35 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141D31B28F0 for ; Wed, 2 Jul 2014 03:20:32 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so9318638wib.12 for ; Wed, 02 Jul 2014 03:20:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=X7pHarxMSiIQLZ4YViMs87NGIzeNh7PdlyzBdf4XMWY=; b=UpXGmwCIGpMWWhEjc7D1kFdwBptnupChbAZJXYqclZ7VyYmeaWts/iYrEsgnbo3gOd E2U+eqOkqTKaEAgW1Lf+nvuYTZyBxaXoLsK8jnRL1oM7C8dANb1qCJXUHNxFxLlEVpiG bYVxjQJ2AbeXGQ1k/w9bjbKdC8vGhTSNUkJhJAuMuP3KXkT8vGLU3YSAcmIirDoJ2V7F jur0QXV3HXaxhSuMCC8B5birJRYmrHzSBCPG2MI/JLztLEhFCBn2bpEF8I7YLwhh7J1k KJ4TuKYRwac2CU6Xpiffv2lgyuz1giM/jjLKCtyLHmFe949d1pZg35Sd6Zxpi2/EPl/p gmBA== X-Gm-Message-State: ALoCoQmCc8wG/kWmozWm3nFSo8DJpehog0oA/csRYDC8m4zoEGwIMmdjtk8XCohKV9QTpuwbS8PL X-Received: by 10.180.75.5 with SMTP id y5mr3548499wiv.9.1404296053975; Wed, 02 Jul 2014 03:14:13 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:35a5:f8a8:c3e0:36cb? ([2001:660:330f:a4:35a5:f8a8:c3e0:36cb]) by mx.google.com with ESMTPSA id nb8sm53546147wic.18.2014.07.02.03.14.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 03:14:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Luigi Iannone In-Reply-To: <20140702101235.30470.80375.idtracker@ietfa.amsl.com> Date: Wed, 2 Jul 2014 12:14:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <867C9B78-5AF9-484F-A021-B1407145D151@gigix.net> References: <20140702101235.30470.80375.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/tGDOsMhEsImoTOelAvNNiSFcSXI Cc: lisp@ietf.org, i-d-announce@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-mgmnt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 10:20:36 -0000 Hi All, this is the EID Block Management document updated as discussed during = last meeting in London. Please review ;-) ciao Luigi On 02 Jul 2014, at 12:12, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. >=20 > Title : LISP EID Block Management Guidelines > Authors : Luigi Iannone > Roger Jorgensen > David Conrad > Filename : draft-ietf-lisp-eid-block-mgmnt-02.txt > Pages : 13 > Date : 2014-07-02 >=20 > Abstract: > This document proposes an allocation framework for the management of > the LISP EID address prefix. The framework described relies on > hierarchical distribution of the address space with sub-prefixes > allocated on a temporary basis to requesting organizations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-mgmnt-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 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jul 2 14:12:44 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA7C1B2A9F for ; Wed, 2 Jul 2014 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNFbA-YBmooz for ; Wed, 2 Jul 2014 14:12:35 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B40E1B2A9D for ; Wed, 2 Jul 2014 14:12:35 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kq14so13116377pab.6 for ; Wed, 02 Jul 2014 14:12:34 -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=2F//TwtSHxLCPr/dHyyuN5ruQqAIvTpIpFXvPnPfCc4=; b=pTFwq5vJHKOVfpqJBm4BCUKQtaacESiIk/bUa/5rx8hAIzwyMMJtLhzJWkOOP6rV61 UHCUnTATkcIrebFSHrbH0EBqdwsocz/xvMQpO8YLqL40oWb3NTbkmT8VRal8B/00TlG5 E3910ondKuKXSYno5wtw3hwCX9HR3HJH3F05q4fOXsZ0xh7comtitdZm4h34R21k7VUm psP4hjrMSqqRY4dGaqRzMrYqW1Bz4v6TUXTkgcpKZhk4CAYeKm07DjBK3FoB0+xnx6a4 vzW+IaT6kRVSpsvQ+xMqSVD+NkmXLP49zQH+3LDi/CnpaWr2m5PTMZSJ2WmsnRKgxx4r z36A== X-Received: by 10.68.225.74 with SMTP id ri10mr421088pbc.116.1404335554759; Wed, 02 Jul 2014 14:12:34 -0700 (PDT) Received: from [172.20.10.3] (mobile-198-228-213-024.mycingular.net. [198.228.213.24]) by mx.google.com with ESMTPSA id z5sm2702847pdl.56.2014.07.02.14.12.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 14:12:33 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_09E91ED2-3E30-4E0B-91B4-AED306B9FD5C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <684A8FEC-35CF-40CA-AE2D-16FA61C6C11A@telecom-paristech.fr> Date: Wed, 2 Jul 2014 14:12:29 -0700 Message-Id: <16712457-9A07-44FC-8F9F-DCFB442BA9EE@gmail.com> References: <684A8FEC-35CF-40CA-AE2D-16FA61C6C11A@telecom-paristech.fr> To: Luigi Iannone X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/rnU3gH738Ld4SUdxSBK0Ia20pL0 Cc: LISP mailing list list Subject: Re: [lisp] Review of draft-farinacci-lisp-rig-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 21:12:41 -0000 --Apple-Mail=_09E91ED2-3E30-4E0B-91B4-AED306B9FD5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See comments inline. A new draft and diff file is enclosed. What I = didn't respond to I agree with and made changes to the draft. >> to store and propagate those mappings globally. This >> document focuses on the LISP-DDT [LISP-DDT] mapping database = system. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> 3. Definition of Terms >>=20 >>=20 > I would put the definitions of terms as appendix. This document is not = authoritative on these=20 > definitions. An appendix to help reading is enough. Is it okay if I keep it this way. All the protocol documents have the = Definition of Terms section right after the Introduction section. I = would like to keep it consistent. > Check the eid block documents as example: >=20 > http://tools.ietf.org/html/draft-ietf-lisp-eid-block-09 > http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-01 >=20 >=20 >> 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 >>=20 > [snip] >>=20 >> Farinacci, et al. Expires September 18, 2014 [Page = 7] >> Internet-Draft LISP-DDT Referral Internet Groper (RIG) March = 2014 >>=20 >>=20 >> 4. Basic Overview >>=20 >>=20 > Just to ease even more the reading wouldn=92t be helpful put how = mapping lookup works in DDT? >=20 > Something describing by text the content of slide 7 of: >=20 > http://tools.ietf.org/agenda/83/slides/slides-83-lisp-8.pdf Added a opening paragraph to the Basic Overview section. Let me know if = you think it is sufficient. I wanted to keep it brief and to the point. >=20 >> message exchange. >>=20 >> A possible syntax for a rig command could be: >>=20 >> rig [instance-id ] to [follow-all-referrals] >>=20 >> Parameter description: >>=20 >> [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. >>=20 >> : is either a Fully Qualified Domain Name or a destination = EID >> that is being queried in the LISP-DDT mapping database. >>=20 >> : 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. >>=20 >> [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. >>=20 > The text above is unclear. >=20 > If follow-all-referrals is present then rig follows all RLOCs: that is = OK. >=20 > If the option is not present why should the rig command follow the = first RLOC?=20 It doesn't. It is up to the implementation to decide which referral node = is used. And most implementations I am aware of will hash the EID-prefix = being looked up (from the Map-Request) will be used so you can = load-split Map-Requests across referral nodes. > The initial description of rig (first paragraph section 4) just states = the upon reception of a Map-Referral, > its content is displayed to the user, it does not mention that any = RLOC is followed to go down the DDT tree. >=20 > Why not adding a =93follow-first-referral=94 option to actually follow = the first RLOC. The implementations don't support such an option because that is not the = way it was implemented or described in the DDT spec. >=20 >> 5. Implementation Details >>=20 >> 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. >>=20 >> The IOS syntax is: >>=20 >> rig [instance-id ] to [follow-all-referrals] >>=20 >> The NX-OS syntax is: >>=20 >> rig [instance-id ] | { | }} >> to { | { | }} >>=20 >> Here is some sample IOS output: >>=20 >> Router# rig 12.0.1.1 to 1.1.1.1 >>=20 >> 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 >>=20 >> 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 >>=20 >> 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 >>=20 >>=20 >>=20 >>=20 > Any other implementation available? Steffann has a ddt_query script = written in python... I would be glad to add the output if Steffan is willing to provide it. >=20 >=20 >> 8. References >>=20 >> 8.1. Normative References >>=20 >> [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, >> September 1981. >>=20 > Delete this reference it is never cited. It is in the definition of "Routing Locator (RLOC)": A RLOC is an IPv4 = =20 or IPv6 = =20 address of an egress tunnel router (ETR). A RLOC is the output = =20 of an EID-to-RLOC mapping lookup. An EID maps to one or more = =20 RLOCs. Typically, RLOCs are numbered from = =20 topologically-aggregatable blocks that are assigned to a site at = =20 each point to which it attaches to the global Internet; where = =20 the topology is defined by the connectivity of provider = =20 networks, RLOCs can be thought of as PA addresses. Multiple = =20 RLOCs can be assigned to the same ETR device or to multiple ETR = =20 devices at a site. >=20 >>=20 >> [RFC1034] Mockapetris, P., "Domain names - concepts and = facilities", >> STD 13, RFC 1034, November 1987. >>=20 > This is used in the definition of terms section and since this = document is not authoritative on > those definitions it might be better to put the reference as = informative. >>=20 >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >>=20 > As far as I can see there is not 2119 notation actually concerning = rig, IMHO we can drop this reference. I will keep it there since there is a reference to 2119 and we MAY add = such language in the future. Dino --Apple-Mail=_09E91ED2-3E30-4E0B-91B4-AED306B9FD5C Content-Disposition: attachment; filename=rfcdiff-lisp-rig-03-to-04.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-rig-03-to-04.html" Content-Transfer-Encoding: quoted-printable wdiff draft-farinacci-lisp-rig-03.txt = draft-farinacci-lisp-rig-04.txt

Internet Engineering Task Force                             D. Farinacci
Internet-Draft                                               lispers.net
Intended status: Experimental                                    A. Jain
Expires: September 18, 2014 =
January 3, 2015            =
                    Juniper Networks
                                                             I. Kouvelas
                                                                D. Lewis
                                                           cisco Systems
                                                          March 17,
                                                            =
July 2, 2014

                LISP-DDT Referral Internet Groper (RIG)
                      draft-farinacci-lisp-rig-03
                      draft-farinacci-lisp-rig-04

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 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 18, 2014. January 3, 2015.

Copyright Notice

   Copyright (c) 2014 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
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . =
.  4   2
   3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .  =
5   3
   4.  Basic Overview  . . . . . . . . . . . . . . . . . . . . . . . =
.  8   5
   5.  Implementation Details  . . . . . . . . . . . . . . . . . . . =
. 10   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . =
12   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . =
13   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . =
. 14   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . =
. 14   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . . =
. 14  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . =
. 15  10
   Appendix B.  Document Change Log  . . . . . . . . . . . . . . . . =
. 16  10
     B.1.  Changes to draft-farinacci-lisp-rig-03.txt . =
draft-farinacci-lisp-rig-04.txt  . . . . =
. . . 16  10
     B.2.  Changes to draft-farinacci-lisp-rig-02.txt . =
draft-farinacci-lisp-rig-03.txt  . . . . =
. . . 16  10
     B.3.  Changes to draft-farinacci-lisp-rig-01.txt . =
draft-farinacci-lisp-rig-02.txt  . . . . =
. . . 16  10
     B.4.  Changes to draft-farinacci-lisp-rig-00.txt =
draft-farinacci-lisp-rig-01.txt  . . =
. . . . .  11
     B.5.  Changes to draft-farinacci-lisp-rig-00.txt  . =
. . . . . 16 =
.  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . =
. 17  11

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

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.

   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.

   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

   The LISP Delegated Database Tree =
[LISP-DDT], is a hierarchical,
   distributed database which embodies the delegation of authority to
   provide mappings from LISP Endpoint Identifiers (EIDs) to Routing
   Locators (RLOCs).  It is a statically-defined distribution of the EID
   namespace among a set of LISP-speaking servers, called DDT nodes.
   Each DDT node is configured as "authoritative" for one or more EID-
   prefixes, along with the set of RLOCs for Map Servers or "child" DDT
   nodes to which more-specific EID-prefixes are delegated.

   Map-Resolvers send Map-Requests to the DDT hierarchy and maintain
   referral-caches by receiving Map-Referral messages from DDT nodes.
   Map-Resolvers follow the DDT hierarchy for a given EID lookup based
   on the EID-prefix and delegation referrals contained in the Map-
   Referral messages.  The intention of rig is to perform the same
   behavior of a Map-Resolver used as a management tool for the network
   administrator.

   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  A 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>]: =
<iid>>]:   is the =
instance-ID portion of the Extended
      EID used as VPN identifer. identifier.  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 [RFC6830], [LISP-DDT], [RFC6833], and [RFC6833] [LISP-THREATS]
   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-DDT]
              Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
              Delegated Database Tree", draft-ietf-lisp-ddt-04.txt (work
              in progress), September 2014.

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

   [LISP-THREATS]
              Iannone, L., Saucez, D., Ermagan, V., and A. Jain, O. =
Bonaventure, "LISP
              Delegated Database Tree", =
draft-ietf-lisp-ddt-01.txt Threats
              Analysis", draft-ietf-lisp-threats-09.txt =
(work in progress).
              progress), April 2014.

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

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

   o  Draft posted July 2014.

   o  Added LISP-DDT basic operation description in the Basic Overview
      section.

   o  Fix editorial comments from Luigi Iannone.

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

   o  Draft posted March 2014.

   o  Resetting timer for expired draft.

B.2.

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

B.4.  Changes to =
draft-farinacci-lisp-rig-01.txt

   o  Draft posted March 2012.

   o  Updated reference to LISP-DDT".

B.4.

B.5.  Changes to =
draft-farinacci-lisp-rig-00.txt

   o  Initial draft posted March 2012.

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

X-Generator: pyht 0.35 = --Apple-Mail=_09E91ED2-3E30-4E0B-91B4-AED306B9FD5C Content-Disposition: attachment; filename=draft-farinacci-lisp-rig-04.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-farinacci-lisp-rig-04.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force D. Farinacci Internet-Draft lispers.net Intended status: Experimental A. Jain Expires: January 3, 2015 Juniper Networks I. Kouvelas D. Lewis cisco Systems July 2, 2014 LISP-DDT Referral Internet Groper (RIG) draft-farinacci-lisp-rig-04 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 January 3, 2015. Copyright Notice Copyright (c) 2014 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 January 3, 2015 [Page 1] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Details . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 B.1. Changes to draft-farinacci-lisp-rig-04.txt . . . . . . . 10 B.2. Changes to draft-farinacci-lisp-rig-03.txt . . . . . . . 10 B.3. Changes to draft-farinacci-lisp-rig-02.txt . . . . . . . 10 B.4. Changes to draft-farinacci-lisp-rig-01.txt . . . . . . . 11 B.5. Changes to draft-farinacci-lisp-rig-00.txt . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 [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 distributed 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. Farinacci, et al. Expires January 3, 2015 [Page 2] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 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. 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 Farinacci, et al. Expires January 3, 2015 [Page 3] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 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 [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 Farinacci, et al. Expires January 3, 2015 [Page 4] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 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 The LISP Delegated Database Tree [LISP-DDT], is a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID- prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. Map-Resolvers send Map-Requests to the DDT hierarchy and maintain referral-caches by receiving Map-Referral messages from DDT nodes. Map-Resolvers follow the DDT hierarchy for a given EID lookup based on the EID-prefix and delegation referrals contained in the Map- Referral messages. The intention of rig is to perform the same behavior of a Map-Resolver used as a management tool for the network administrator. 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 A 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] Farinacci, et al. Expires January 3, 2015 [Page 5] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 Parameter description: [instance-id >]: is the instance-ID portion of the Extended EID used as VPN identifier. 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: 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 January 3, 2015 [Page 6] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 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 January 3, 2015 [Page 7] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 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 January 3, 2015 [Page 8] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 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], [RFC6833], and [LISP-THREATS] 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-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-04.txt (work in progress), September 2014. [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. [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. Farinacci, et al. Expires January 3, 2015 [Page 9] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 8.2. Informative References [LISP-THREATS] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Threats Analysis", draft-ietf-lisp-threats-09.txt (work in progress), April 2014. [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. 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-04.txt o Draft posted July 2014. o Added LISP-DDT basic operation description in the Basic Overview section. o Fix editorial comments from Luigi Iannone. B.2. Changes to draft-farinacci-lisp-rig-03.txt o Draft posted March 2014. o Resetting timer for expired draft. B.3. 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. Farinacci, et al. Expires January 3, 2015 [Page 10] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) July 2014 B.4. Changes to draft-farinacci-lisp-rig-01.txt o Draft posted March 2012. o Updated reference to LISP-DDT". B.5. Changes to draft-farinacci-lisp-rig-00.txt o Initial draft posted March 2012. 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 Email: atjain@juniper.net Isidor Kouvelas cisco Systems Tasman Ave. San Jose, California USA Email: kouvelas@cisco.com Darrel Lewis cisco Systems Tasman Ave. San Jose, California USA Email: darlewis@cisco.com Farinacci, et al. Expires January 3, 2015 [Page 11] --Apple-Mail=_09E91ED2-3E30-4E0B-91B4-AED306B9FD5C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 --Apple-Mail=_09E91ED2-3E30-4E0B-91B4-AED306B9FD5C-- From nobody Fri Jul 4 06:16:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680D31B2925 for ; Fri, 4 Jul 2014 06:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9RqpZ0cv9-X for ; Fri, 4 Jul 2014 06:16:55 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 44EBA1B2875 for ; Fri, 4 Jul 2014 06:16:55 -0700 (PDT) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id s64DGrfi005543 for ; Fri, 4 Jul 2014 15:16:53 +0200 Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id 464623CE for ; Fri, 4 Jul 2014 15:16:53 +0200 (CEST) Received: by mail-lb0-f179.google.com with SMTP id z11so1158631lbi.38 for ; Fri, 04 Jul 2014 06:16:52 -0700 (PDT) X-Received: by 10.152.29.200 with SMTP id m8mr8522779lah.4.1404479812542; Fri, 04 Jul 2014 06:16:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.130.196 with HTTP; Fri, 4 Jul 2014 06:16:32 -0700 (PDT) In-Reply-To: <20140704130144.20502.78491.idtracker@ietfa.amsl.com> References: <20140704130144.20502.78491.idtracker@ietfa.amsl.com> From: Alberto Rodriguez-Natal Date: Fri, 4 Jul 2014 22:16:32 +0900 Message-ID: To: "lisp@ietf.org list" Content-Type: multipart/alternative; boundary=089e0158c29c52291b04fd5df0aa Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/-iMvZGiWMitVsKlw9RkoKiI2Dhc Subject: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 13:16:58 -0000 --089e0158c29c52291b04fd5df0aa Content-Type: text/plain; charset=UTF-8 Dear all, We have just submitted a new draft discussing OAM (Operations Administration Management) use-cases and requirements for LISP. Please, feel free to review it and provide feedback. Thanks, Alberto ---------- Forwarded message ---------- From: Date: Fri, Jul 4, 2014 at 10:01 PM Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt To: Albert Cabellos-Aparicio , Marc Portoles-Comeras < mportole@cisco.com>, Alberto Rodriguez-Natal , Michael Kowal , Darrel Lewis , Fabio Maino < fmaino@cisco.com> A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt has been successfully submitted by Alberto Rodriguez-Natal and posted to the IETF repository. Name: draft-rodrigueznatal-lisp-oam Revision: 00 Title: LISP-OAM (Operations Administration Management): Use cases and requirements Document date: 2014-07-04 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rodrigueznatal-lisp-oam-00.txt Status: https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-oam/ Htmlized: http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00 Abstract: This document describes Operations Administration and Management (OAM) use-cases and the requirements that they have towards the LISP architecture. 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. The IETF Secretariat --089e0158c29c52291b04fd5df0aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear all,

We have just submitt= ed a new draft discussing OAM (Operations Administration Management) use-ca= ses and requirements for LISP.

Please, feel free to review it = and provide feedback.

Thanks,
Alberto

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jul 4, 2014 at 10:01 PM
Subject: New Version Notification for= draft-rodrigueznatal-lisp-oam-00.txt
To: Albert Cabellos-Aparicio <<= a href=3D"mailto:acabello@ac.upc.edu">acabello@ac.upc.edu>, Marc Por= toles-Comeras <mportole@cisco.com<= /a>>, Alberto Rodriguez-Natal <= arnatal@ac.upc.edu>, Michael Kowal <mikowal@cisco.com>, Darrel Lewis <darlewis@cisco.com>, Fabio Maino <fmaino@cisco.com>

A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt
has been successfully submitted by Alberto Rodriguez-Natal and posted to th= e
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-rodrigueznatal-lisp-oam
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LISP-OAM (Operations Administratio= n Management): Use cases and requirements
Document date: =C2=A02014-07-04
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://www.ietf.org/internet-drafts/draft-rodrigueznatal-lisp-oam-00.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.= ietf.org/doc/draft-rodrigueznatal-lisp-oam/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/dr= aft-rodrigueznatal-lisp-oam-00

Abstract:
=C2=A0 =C2=A0This document describes Operations Administration and Manageme= nt
=C2=A0 =C2=A0(OAM) use-cases and the requirements that they have towards th= e LISP
=C2=A0 =C2=A0architecture.

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

The IETF Secretariat

--089e0158c29c52291b04fd5df0aa-- From nobody Fri Jul 4 07:34:47 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4641B2D66; Fri, 4 Jul 2014 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o71LgsQx4JlY; Fri, 4 Jul 2014 07:34:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A01B2990; Fri, 4 Jul 2014 07:34:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704143442.24006.24649.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 07:34:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/iq6xWytDI8BfWR6FP7tEE4jRt84 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:34:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Threats Analysis Authors : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-10.txt Pages : 19 Date : 2014-07-04 Abstract: This document proposes a threat analysis of the Locator/Identifier Separation Protocol (LISP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-threats-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-threats-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 07:48:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD351B2D99 for ; Fri, 4 Jul 2014 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pngtHmTON9xK for ; Fri, 4 Jul 2014 07:48:56 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864B81B2D72 for ; Fri, 4 Jul 2014 07:48:56 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so3947325wib.0 for ; Fri, 04 Jul 2014 07:48:53 -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=nqiXdKULYVh/gIZl7F01PfzH8TDr+PG4EDIUg4dCVNo=; b=kCaQjkkI+UuP9cjtM10sDfjfF8csWJaQWAEW4gwWlc7HQCsaWoXYNvjOg82c3zQHOh V1FJRq0kjM78RXaNeKcXhTwnNNb8IUhytwsGdswu4hlfL0+PSYslAqJTq/oZ8c+5C883 Y7/77lUeI+Lre/Ycgx1JHjuN5L+NiLcc0bkpJcmVqOML4DJ/wZdmcTJfRPeLRobMupdw oiMMagPHeaEBiZqjxLh47mUwJgm0B+MYgf17Lv038Jr5WVXs0ZK2GKstu0BwbUY9HMSN raKSnuLWRuWVuOCdIAOsUYr+Bkm+OxyzvvnFpXmUCCO7FHMeWtFAKJl2HxxkvX6ROBh7 XRNg== X-Received: by 10.180.39.33 with SMTP id m1mr18647298wik.82.1404485332225; Fri, 04 Jul 2014 07:48:52 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id q11sm80007084wib.14.2014.07.04.07.48.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 07:48:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: <20140704143442.24006.24649.idtracker@ietfa.amsl.com> Date: Fri, 4 Jul 2014 16:48:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6448EA24-B1FB-4F6D-8330-5A6BD80EE7BD@gmail.com> References: <20140704143442.24006.24649.idtracker@ietfa.amsl.com> To: LISP mailing list list X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/GffKctQMZa-aj5iWt4hahfD7usI Cc: lisp-chairs@tools.ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-threats-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:48:58 -0000 Dear all, We just submitted a revision of the threat document. We would like to thank the WG in general and Ron in particular for all the comments that have been provided. As you can see, the document changed in depth so to cover as much attack = as possible. See you in Toronto.=20 Damien Saucez=20 On 04 Jul 2014, at 16:34, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. >=20 > Title : LISP Threats Analysis > Authors : Damien Saucez > Luigi Iannone > Olivier Bonaventure > Filename : draft-ietf-lisp-threats-10.txt > Pages : 19 > Date : 2014-07-04 >=20 > Abstract: > This document proposes a threat analysis of the Locator/Identifier > Separation Protocol (LISP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lisp-threats-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-threats-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jul 7 15:34:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701381B297D for ; Mon, 7 Jul 2014 15:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.039 X-Spam-Level: X-Spam-Status: No, score=-14.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To_hVod6Ud5j for ; Mon, 7 Jul 2014 15:34:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2411B297B for ; Mon, 7 Jul 2014 15:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22390; q=dns/txt; s=iport; t=1404772494; x=1405982094; h=mime-version:subject:from:in-reply-to:date:message-id: references:to; bh=JTBL6NIyTk5Nc0lYDmTtqdty2ZOUmQUI+z5Cpbw0AY4=; b=DoXdpcovL26b7haPG0RMUPogKsfep40KRzNNEr5lNleRy7p040R/yE/n 6xu60csUe+FG+o5jrrBmVgWyACsy/nVwbIEOg00KtSSkvP8KhQKz6SpUQ FdvDsKMiWNXqUTC9Xb+msigheCEsUSRtE3R9WKspWMSfwckCcSv4lQ+pb Y=; X-Files: draft-shen-lisp-multiprovider-vpn-00.txt : 19116 X-IronPort-AV: E=Sophos;i="5.01,621,1400025600"; d="txt'?scan'208,217";a="335223105" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jul 2014 22:34:54 +0000 Received: from [10.154.165.86] ([10.154.165.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s67MYqeo022231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jul 2014 22:34:53 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_7997F27B-BFCA-4DE0-B9CD-A63371AB095F" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Naiming Shen In-Reply-To: <8C31D237-B9AD-47E5-B1BD-B074B801732C@cisco.com> Date: Mon, 7 Jul 2014 15:34:53 -0700 Message-Id: <4ED21992-55FE-4BAC-AFF4-F39C28CEFD06@cisco.com> References: <8C31D237-B9AD-47E5-B1BD-B074B801732C@cisco.com> To: "lisp@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/9UA2AaYKbRhqijofo9qfcz1jY9M Subject: [lisp] LISP Multi-Provider VPN draft X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:34:58 -0000 --Apple-Mail=_7997F27B-BFCA-4DE0-B9CD-A63371AB095F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry, just missed the submission deadline, but attached is a draft on = multi-provider VPN where the communication is among the providers who maintain their = own mapping database systems and have their own security mechanism for the = LISP overlay. Please review and comment. thanks. - Naiming/Dino --Apple-Mail=_7997F27B-BFCA-4DE0-B9CD-A63371AB095F Content-Type: multipart/mixed; boundary="Apple-Mail=_107ED8B7-4B5C-461D-AC3C-384745600383" --Apple-Mail=_107ED8B7-4B5C-461D-AC3C-384745600383 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Sorry, just missed the submission deadline, but attached is a draft on multi-provider

VPN where the communication is among the providers who maintain their own
mapping database systems and have their own security mechanism for the LISP

overlay. Please review and comment.

thanks.
- Naiming/Dino

--Apple-Mail=_107ED8B7-4B5C-461D-AC3C-384745600383 Content-Disposition: attachment; filename=draft-shen-lisp-multiprovider-vpn-00.txt Content-Type: text/plain; name="draft-shen-lisp-multiprovider-vpn-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force N. Shen Internet-Draft cisco Systems Intended status: Experimental D. Farinacci Expires: January 8, 2015 lispers.net July 7, 2014 LISP Multi-Provider VPN Use-Cases draft-shen-lisp-multiprovider-vpn-00 Abstract This document describes how LISP sites communicate with each other in a VPN when there are multiple mapping database systems administered by multiple providers. The detail of VPN segmentation across mapping databases will be provided. 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 8, 2015. Copyright Notice Copyright (c) 2014 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. Shen & Farinacci Expires January 8, 2015 [Page 1] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. LISP Mapping Database System . . . . . . . . . . . . . . . . 5 6. LISP Packet Flow . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Packet from Site1 to Site2 . . . . . . . . . . . . . . . 7 6.2. Packet from Site1 to Site3 . . . . . . . . . . . . . . . 7 6.3. Packet from Site1 to Site4 . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 This document describes how the Locator/Identifier Separation Protocol (LISP) [RFC6830] is used for Multi-Provider LISP VPN where the providers maintain their own local LISP mapping databases, and their own security and crypto mechanisms within the provider's LISP network. Each provider will have a number of Gateway Tunnel Routers (GTR) to send and receive LISP encapsulated packets to and from the other provider. Those Gateway Tunnel Routers behave the same as the Re-Encapsulating Tunnel Routers (RTRs) on traffic engineered LISP paths. Special security mechanisms between a pair of GTRs from two providers can be enforced, such as firewall and IPSec encryption can be applied over this Multi-Provider LISP overlay tunnel. This specification will define how an Explicit Locator Path (ELP) [LISP-LCAF] can be used for an ITR to encapsulate an Multi-Provider VPN packet to its own Gateway Tunnel Router (GTR), then to the peering provider's Gateway Tunnel Router (GTR), and finally to the peering provider's ETR. This specification will examine how each provider's GTR can interface with its own local LISP mapping database system and allow the instance-ID allocated to sites of one provider can be different from the instance-ID allocated to sites in the other providers. This allows policy and control to be contained within Shen & Farinacci Expires January 8, 2015 [Page 2] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 each provider while allowing segmented connectivity across providers with secure LISP overlay. 3. Definition of Terms Mapping Service Provider (MSP): A LISP control-plane network provider which maintains its own LISP mapping database system. LISP Provider Network: Is a delivery network that administers its own mapping database acting as an MSP as well as managing a set of GTRs so multi-provider VPNs can be provided. Re-Encapsulating Tunnel Router (RTR): An RTR is a router that acts as an ETR (or PETR) by decapsulating packets where the destination address in the "outer" IP header is one of its own RLOCs. Then acts as an ITR (or PITR) by making a decision where to encapsulate the packet based on the next locator in the ELP towards the final destination ETR. Gateway Tunnel Router (GTR): An GTR is a router serves as a gateway re-encapsulating tunnel router (RTR) on the edge of the provider's LISP network. It services as an ETR for one LISP network for sending out the packet to the other provider, and as an ITR for the another LISP network when receiving a packet from the other provider. Re-Encapsulating Tunnels: Re-Encapsulating tunneling occurs when an RTR acts as an ETR and then an ITR on a given packet. As an ETR it removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re- routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and they are never statically configured. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration. 4. Overview A packet that is sourced by an EID which is destined for an EID travels across a core network based on the locators that ITR uses as the outer source and destination addresses towards a given ETR. If the Mapping Service Provider (MSP) the ITR uses to obtain the destination ETR's locator address can be a local mapping database or one deployed on globally on the Internet. Shen & Farinacci Expires January 8, 2015 [Page 3] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 In a LISP Provider Network, the security mechanism is usually applied with the LISP tunneled packets within a single administrative organization. When two LISP Provider Networks need to communicate with each other, it is undesirable to have xTRs belong to two organizations to simply exchange the crypto keys. This specification proposes the solution to have the xTRs setup normal LISP overlay to the local GTR, and to have both GTRs of peering LISP Provider Networks to share common crypto keys if needed, and use the LISP re- encapsulation tunnels to have the Multi-Provider VPN packets traffic engineered among two providers without compromising the security aspect of the VPNs and simplify the Multi-Provider secure VPN management. (Mapping DB 1) (Mapping DB 2) Source site (-----------} {-----------) Destination Site ( LISP } { LISP ) +-------+ ( Provider1 } { Provider2 ) +---------+ | \ ( Network } { Network ) / | | seid / ITR ---(---> . --> } { --> . ----)---> ETR deid / | | siid / || ( | } { ^ ) ^^ \ diid | | / || ( | } { | ) || \ | +------+ || ( v } { | ) || +-------+ || ( GTR1 =3D=3D=3D=3D=3D=3D> GTR2 ) || || ( ^^ } { || ) || || (--------||-} {-||--------) || || || || || =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Secure LISP Tunnel Secure LISP Tunnel Typical Multi-Provider Secure VPN Data Path from ITR to ETR This diagram shows the packet flow from Provider1's network into the Provider2's network, and the other direction is logically the same. Although this diagram only showing one pair of GTRs between two providers, but in general, there can be a number of GTRs to be deployed on each side to either load share or for Multi-Provider VPN traffic engineering purposes. The policy agreed upon both providers decides which EIDs/IIDs to be exported to the other provider's mapping database. The ETR in Provider2 network registers the destination EID/IID into its own mapping system (Mapping DB 2); base on the Multi-Provider VPN policies, Provider2 network will provide the VPN mapping information along with the gateway Tunnel Router (GTR2) hop address to Provider1. Shen & Farinacci Expires January 8, 2015 [Page 4] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 Provider1 will provision the Gateway Tunnel Router (GTR1) to register the Multi-Provider VPN LISP mapping into its own mapping database along with the ELP to list the GTR1 and GTR2 as hops. An AS Number [LISP-LCAF] can be part of the EID mapping entry to clearly define the mapping is an Multi-Provider LISP entry and belong to which MSP network. Other usages of this AS Number includes to detect the LISP mapping system looping and to facilitate multi- provider LISP VPN trouble-shooting. 5. LISP Mapping Database System For sites attached to LISP Provider Networks to communicate with one another in a VPN, we assume the EID space is unique, while the IID space is maintained individually by each LISP Provider Network and there is no coordination among providers on the LISP IIDs. The Multi-Provider VPN mapping entries are registered into its own mapping database by the GTRs. Take an example to illustrate the mapping database systems in the Multi-Provider LISP VPN. In this instance, we have 4 LISP sites that want to be part of the same VPN. There are 3 LISP Provider Networks each which manage their own LISP mapping database systems. Each provider allocates IIDs to their local LISP sites and there is no IID space coordination among the MSPs. Shen & Farinacci Expires January 8, 2015 [Page 5] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 AS 65512 AS 65513 10.1.0.0/16 (-----------} {-----------) +-----+ ( LISP } { LISP ) 11.1.0.0/16 |Site1 \ ( ProviderA } { ProviderB ) +------+ | xTR ( Network } { Network ) / Site3 | |IID 1 / +-----(--- . --+ } { +-- . ----)---- xTR | +-----+ ( | } { | ) \ IID 2 | ( | } { | ) +------+ +-----+ ( | } { | ) |Site2 \ ( GTR-A GTR-B ) | xTR ---{--- . --+ }. . . .{ } |IID 1 / (-----------} . . {-----------) +-----+ . . 10.2.0.0/16 . {-- GTR-C --) 12.1.0.0/16 { | ) +------+ { | ) / Site4 | { . ----)---- xTR | { ) \ IID 1 | { LISP ) +------+ { ProviderC ) { Network } {-----------) AS 65514 Four Multi-Provider LISP VPN sites from three LISP Providers In above diagram, there are three LISP Provider Networks and four LISP sites to be provisioned within the same Multi-Provider VPN. MSP A has two LISP sites with the same IID, and with prefix 10.1.0.0/16 in Site1 and 10.2.0.0/16 in Site2, IID 1; The MSP B has one site with IID 2 with prefix 11.1.0.0/16 in Site3 and the MSP C has one site with IID 1 with prefix 12.1.0.0/16 in Site4. The GTR-A, GTR-B and GTR-C are the re-encapsulation tunnel routers to facilitate Multi- Provider VPN communication among the three MSPs. In ProviderA's mapping database (registered by GTR-A): (IID1, 11.1.0.0/16) -> ELP: [GTR-A, (IID2, GTR-B)] [IID1, 12.1.0.0/16) -> ELP: [GTR-A, (IID1, GTR-C)] In ProviderB's mapping database (registered by GTR-B): (IID2, 10.1.0.0/16) -> ELP: [GTR-B, (IID1, GTR-A)] [IID2, 10.2.0.0/16) -> ELP: [GTR-B, (IID1, GTR-A)] [IID2, 12.1.0.0/16) -> ELP: [GTR-B, (IID1, GTR-C)] Shen & Farinacci Expires January 8, 2015 [Page 6] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 In ProviderC's mapping database (registered by GTR-C): (IID2, 10.1.0.0/16) -> ELP: [GTR-C, (IID1, GTR-A)] [IID2, 10.2.0.0/16) -> ELP: [GTR-C, (IID1, GTR-A)] [IID2, 11.1.0.0/16) -> ELP: [GTR-C, (IID2, GTR-B)] 6. LISP Packet Flow Using the same example as in the previous section, this section shows how the VPN packet flow operations either within the same LISP Provider Network sites as well as sites across LISP Provider Networks. 6.1. Packet from Site1 to Site2 This packet flow from 10.1 network to 10.2 network is within the same LISP Provider Network uses the traditional LISP-VPN mechanism [LISP-VPN]. Each ETR registers the site (IID1, eid-prefix) with ProviderA's mapping database. The xTR at Site1 sends the Map- Requests for(IID1, eid) to mapping database, and encapsulates the packet direct to the xTR at Site2. 6.2. Packet from Site1 to Site3 This is the Multi-Provider VPN case. The xTR at Site1 of 10.1 sends a Map-Request for (IID1, 11.1.1.1) to its local LISP mapping database. The returned result will be (IID1, 11.1.0.0/16) with ELP of [GTR-A, (IID2, GTR-B)]. The xTR at Site1 encapsulates to GTR-A with the IID1 in the LISP header. The GTR-A does a lookup on (IID1, 11.1.1.1) in its local mapping database (same as the xTRs) and it will use the second node in the ELP list. The GTR-A encapsulates the packet to GTR-B with IID2 in the LISP header. GTR-B decapsulates and looks up the (IID2, 11.1.1.1) in MSP B's local mapping database, and the RLOC of TR at Site3 is returned. The GTR-B encapsulates the packet to that RLOC. The xTR on Site3 decapsulates the packet and sends the packet to the host of 11.1.1.1. 6.3. Packet from Site1 to Site4 The operation is almost identical as the above sub-section except for that the IIDs between the two sites are the same. Thus there is no IID change during the packet hops across LISP Provider Networks. 7. Security Considerations This specification allows provider's VPN to communicate with each other in a secure fashion. The LISP tunnel from ITR to GTR1 and from GTR2 to ETR may use their own encryption mechanisms with each Shen & Farinacci Expires January 8, 2015 [Page 7] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 provider. There can be cases one provider uses encryption for the LISP overlay while the other provider does not. Also whether or not to use the encryption over the tunnel between the GTR1 and GTR2 depends on the data sensitivity and the underlining network. The GTRs MAY choose to drop the packet if the local security policy does not match Multi-Provider VPN packet attributes. 8. IANA Considerations At this time there are no requests for IANA. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. 9.2. Informative References [LISP-LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-06 (work in progress), 2014. [LISP-VPN] Lewis, D. and G. Schudel, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpns-00 (work in progress), 2014. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Appendix A. Acknowledgments TBD. Appendix B. Document Change Log Initial draft posted on July 2014. Shen & Farinacci Expires January 8, 2015 [Page 8] =0C Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 Authors' Addresses Naiming Shen cisco Systems San Jose, California USA Email: naiming@cisco.com Dino Farinacci lispers.net San Jose, California USA Phone: 408-718-2001 Email: farinacci@gmail.com Shen & Farinacci Expires January 8, 2015 [Page 9] --Apple-Mail=_107ED8B7-4B5C-461D-AC3C-384745600383 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_107ED8B7-4B5C-461D-AC3C-384745600383-- --Apple-Mail=_7997F27B-BFCA-4DE0-B9CD-A63371AB095F-- From nobody Mon Jul 7 17:27:21 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28541B299B for ; Mon, 7 Jul 2014 17:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAwDI3dJIAJR for ; Mon, 7 Jul 2014 17:27:18 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CF71B2999 for ; Mon, 7 Jul 2014 17:27:18 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id BA5F72AA0F; Tue, 8 Jul 2014 00:27:14 +0000 (GMT) Date: Mon, 7 Jul 2014 17:27:27 -0700 From: Marc Binderberger To: Darrel Lewis (darlewis) , pagarwal@broadcom.com, kreeger@cisco.com, Fabio Maino (fmaino) , paulq@cisco.com, michsmit@cisco.com, nyadav@cisco.com Message-ID: <20140707172727580331.8446565a@sniff.de> In-Reply-To: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/ZKVIPoLtn0vCwnl7asD2btwSTlA Cc: lisp@ietf.org Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 00:27:20 -0000 Hello Darrel et al., few questions/comments on your updated draft: 1) not sure Figure 2 and 3 do make much sense as for P=1 the LISP header layout is figure 4. Yes it is a very didactic approach ;-) but at the end the OAM and version bits are there is any case with P=1 - or not? 2) the layout does not fit well with draft-farinacci-lisp-crypto-00. Are there any plans to solve this? Should this at least be mentioned somewhere? 3) probably too trivial but section "3.3. Version Bits" is not mentioning anything about the receiver behaviour. Sure, if you don't know the version, drop it. Or at least I assume this is what you have in mind (?). 4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say When the P bit is set, the N, E, and V bits MUST be set to zero. The receiving (legacy) LISP router will ignore N, E and V bits, when the P bit is set. I would think a receiving legacy LISP router has no idea about the P bit, which is why you explicitly set N/E/V to zero? 5) as you even mention "Ethernet" (or 802.1Q) in the informative reference section, what about a reference to "Network Service Header" ? So just smaller points I make, overall a very interesting document! Best regards, Marc On Fri, 04 Jul 2014 12:45:06 -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : LISP Generic Protocol Extension > Authors : Darrel Lewis > Puneet Agarwal > Larry Kreeger > Fabio Maino > Paul Quinn > Michael Smith > Navindra Yadav > Filename : draft-lewis-lisp-gpe-02.txt > Pages : 15 > Date : 2014-07-04 > > Abstract: > This draft describes extending the Locator/ID Separation Protocol > (LISP) [RFC6830], via changes to the LISP header, with three new > capabilities: support for multi-protocol encapsulation, operations, > administration and management (OAM) signaling, and explicit > versioning. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lewis-lisp-gpe-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Tue Jul 8 08:47:14 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D841A030A for ; Tue, 8 Jul 2014 08:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE77bziLuiNW for ; Tue, 8 Jul 2014 08:47:11 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BDC1B2B31 for ; Tue, 8 Jul 2014 08:47:10 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so5045538wgg.21 for ; Tue, 08 Jul 2014 08:47:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=paAx6NUEIRlQWt6Cl0uW3lQHOIrfixD/zaMQViNZpBM=; b=OpFZepq3Jxv0ip5MQdNmVJ/KCnI+l5Vg0InKxw45fjSy5KSxcMEPZUU81xCK9+4E97 vJKqvlYpfxT3Q4guayWmxT0q39t26X8GIAlr1VIe6ex9o4Bf04exVkditQ0JGiLGaFF9 1P4Dn6hnF5Pb/eufS0m6xL4fzx1M9h93biJxAsvLOpAH9o4zXVXrtBalZeWSomBDNbtl hvw61Lg1+fQw1ekRhSdp423w8AQHkU/uO/2pA2JxKv7RaBRbOti84kmBI49fH4h7rZfR 1ZnaBJqSCHj6Uu7Tb82blvcrz4c40LJzExXizey0sNg/kKDDYCcvHqBEPYE2CLP6ZdzA n39A== X-Gm-Message-State: ALoCoQlDiRYo6Deb9FncDlu8bnwZPTYXzcn10ckcO8hpOWmvNJVAeMykktVK+cNZBVaIDzieByfN X-Received: by 10.194.219.70 with SMTP id pm6mr40459844wjc.53.1404834429290; Tue, 08 Jul 2014 08:47:09 -0700 (PDT) Received: from dhcp164-99.enst.fr (dhcp164-99.enst.fr. [137.194.165.99]) by mx.google.com with ESMTPSA id ch5sm97165584wjb.18.2014.07.08.08.47.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 08:47:07 -0700 (PDT) From: Luigi Iannone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <411A28BE-CC43-4FD7-9969-3F82FEF45DFE@gigix.net> Date: Tue, 8 Jul 2014 17:47:12 +0200 To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Vv2H8-2tYZgvwF8gyuG2E_abZ80 Subject: [lisp] Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:47:12 -0000 Hi All, the preliminary agenda of the LISP WG is now available: https://datatracker.ietf.org/meeting/90/agenda/lisp/ ciao Luigi From nobody Tue Jul 8 13:32:33 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4A1A000F for ; Tue, 8 Jul 2014 13:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBv4-ltd6d5m for ; Tue, 8 Jul 2014 13:32:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AFE1A004A for ; Tue, 8 Jul 2014 13:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4003; q=dns/txt; s=iport; t=1404851546; x=1406061146; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KnVXWDwKzEWFeiU5EFOvHE1LmMjz/BurGHH4QTFVMDk=; b=m62dfRNIbhBoREmoMsvufHPRYDVtHNUcLJND9HBYJ6Rsrzm+Q9wGundp m3K+4rZV5hxCFWm2rYsJGiPi1DlIZNsFcQPy/z9mEqPnqUFUfPVp/Mhdu 82zkl5bnDfhUMBrKegmWGw75vn/snMjqMQ3Iws7LM2zj7FX7u+CLRY9Kh I=; X-IronPort-AV: E=Sophos;i="5.01,627,1400025600"; d="scan'208";a="59253827" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 08 Jul 2014 20:32:26 +0000 Received: from [10.154.212.111] ([10.154.212.111]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s68KWNo5026489; Tue, 8 Jul 2014 20:32:23 GMT Message-ID: <53BC5569.4000002@cisco.com> Date: Tue, 08 Jul 2014 13:32:41 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marc Binderberger , Darrel Lewis , pagarwal@broadcom.com, kreeger@cisco.com, paulq@cisco.com, michsmit@cisco.com, nyadav@cisco.com References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> In-Reply-To: <20140707172727580331.8446565a@sniff.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/IJNi9pLHx3YHl3bVO2uVdW46Ltw Cc: lisp@ietf.org Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:32:31 -0000 On 7/7/14, 5:27 PM, Marc Binderberger wrote: > Hello Darrel et al., > > few questions/comments on your updated draft: > > 1) not sure Figure 2 and 3 do make much sense as for P=1 the LISP header > layout is figure 4. Yes it is a very didactic approach ;-) but at the end the > OAM and version bits are there is any case with P=1 - or not? Right, we are trying to show a feature per each sub section. Maybe we should explicitly mark as "0/1" the bits that are not shown in a given subsection. We'll work on that. > > 2) the layout does not fit well with draft-farinacci-lisp-crypto-00. Are > there any plans to solve this? Should this at least be mentioned somewhere? Both this draft and lisp-crypto are proposals to extend the LISP encap with new features. I don't think they need to refer each other at this point. I just note that by adding multiprotocol support, one could add a shim header that provides encryption services to the LISP payload. > > 3) probably too trivial but section "3.3. Version Bits" is not mentioning > anything about the receiver behaviour. Sure, if you don't know the version, > drop it. Or at least I assume this is what you have in mind (?). good point. Will add. > > 4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say > > When the P bit is set, the N, E, and V bits MUST be set to zero. The > receiving (legacy) LISP router will ignore N, E and V bits, when the > P bit is set. > > I would think a receiving legacy LISP router has no idea about the P bit, > which is why you explicitly set N/E/V to zero? Right. Per LISP specification P bit is ignored, and given that NEV are set to zero, the next protocol field is ignored too. We'll rephrase the sentence to make it more clear. > > 5) as you even mention "Ethernet" (or 802.1Q) in the informative reference > section, what about a reference to "Network Service Header" ? Right. Will add. Thanks for the review! Fabio > > So just smaller points I make, overall a very interesting document! > > > Best regards, > Marc > > > > > On Fri, 04 Jul 2014 12:45:06 -0700, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : LISP Generic Protocol Extension >> Authors : Darrel Lewis >> Puneet Agarwal >> Larry Kreeger >> Fabio Maino >> Paul Quinn >> Michael Smith >> Navindra Yadav >> Filename : draft-lewis-lisp-gpe-02.txt >> Pages : 15 >> Date : 2014-07-04 >> >> Abstract: >> This draft describes extending the Locator/ID Separation Protocol >> (LISP) [RFC6830], via changes to the LISP header, with three new >> capabilities: support for multi-protocol encapsulation, operations, >> administration and management (OAM) signaling, and explicit >> versioning. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lewis-lisp-gpe-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> From nobody Tue Jul 8 13:39:08 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032711A002A for ; Tue, 8 Jul 2014 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsNG38QVNCsY for ; Tue, 8 Jul 2014 13:39:05 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63761A000E for ; Tue, 8 Jul 2014 13:39:04 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id v10so7673253pde.6 for ; Tue, 08 Jul 2014 13:39:04 -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=hksg9hR130pG68N+SZGBSqk+3ilO8cWaOxi2CUsWOOs=; b=V8ZlAI2vnpzsAWaHpxfJb/1c/uES8JWB117R9REXw95g65AgZ+8RCG9hIz1ZBlhwR5 PWpLw4SosJ3OMjTyzLYIpCALBAAU5Md60rvjvEOJXC8wfglFnS5kB8WIamQbUrBZzgNL l5KFBX4bld4wTQz5PpBOOmSsFSxiZindJWXE5awm/1vSyzcb+uVk5HAWnw/8yhGCyKow VxrcDkMnfd3MleGUrC13uPStaUbySYgNTpoq/0BuNhjBcnCPjS5Gg0Gy6valqWt8M49M i/Q0USXXya/XtkfSQjOy8ePAkEkdfrDFR0FBDIvtAVNdfsM4Ny0f03w5jaL4T4xhhtjJ 0x1g== X-Received: by 10.66.65.138 with SMTP id x10mr7750250pas.17.1404851944534; Tue, 08 Jul 2014 13:39:04 -0700 (PDT) Received: from [192.168.1.191] ([108.211.178.71]) by mx.google.com with ESMTPSA id j6sm25574368pdn.23.2014.07.08.13.39.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 13:39:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <53BC5569.4000002@cisco.com> Date: Tue, 8 Jul 2014 13:39:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FAB93E6-780E-4C92-A791-4B514FF2770E@gmail.com> References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Q8EvDDu9OZC6rCc5kSmquoarHyQ Cc: lisp@ietf.org, Puneet Agarwal , nyadav@cisco.com, Larry Kreeger , "Michael Smith \(michsmit\)" Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:39:06 -0000 >>=20 >> 2) the layout does not fit well with draft-farinacci-lisp-crypto-00. = Are >> there any plans to solve this? Should this at least be mentioned = somewhere? >=20 >=20 > Both this draft and lisp-crypto are proposals to extend the LISP encap = with new features. I don't think they need to refer each other at this = point. >=20 > I just note that by adding multiprotocol support, one could add a shim = header that provides encryption services to the LISP payload. When I selected the location of the K bits, I knew the P-bit was = predefined in the gpe draft, so I didn't use that location. There are no = flag bits left if GPE and lisp-crypto are accepted as working group = items.=20 Dino From nobody Tue Jul 8 17:04:22 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B501A0194 for ; Tue, 8 Jul 2014 17:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMvlclTOYQaI for ; Tue, 8 Jul 2014 17:04:19 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE971A0190 for ; Tue, 8 Jul 2014 17:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 50795681C76; Tue, 8 Jul 2014 17:04:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id ACC35681C68; Tue, 8 Jul 2014 17:04:16 -0700 (PDT) Message-ID: <53BC86FF.4010906@joelhalpern.com> Date: Tue, 08 Jul 2014 20:04:15 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fabio Maino , Marc Binderberger , Darrel Lewis , pagarwal@broadcom.com, kreeger@cisco.com, paulq@cisco.com, michsmit@cisco.com, nyadav@cisco.com References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> In-Reply-To: <53BC5569.4000002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/0Vz0JRZ5RtvPkRI33L9D9b0ucp8 Cc: lisp@ietf.org Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:04:21 -0000 I am very concerned about the compatibility behavior of this. If the sender is setting the P bit, and the next header, then he presumably thinks that is useful to the receiver. If the receiver is ignoring the P bit, and ignoring the field occupied by the next-header, how will the receiver know what the content is? Are we assuming that the sender will magically know what packet type the receiver expects, even though the sender is capable of sending several different packet types? I am also concerned that this is removing several features that the working group has, up till now, deemed important. If this gpe is important, then we will have to ensure that we do not count on any of those features for reliable operation. If that is our intent, then the document really needs to say so explicitly so that WG adoption actually represents agreement to those constraints. Yours, Joel On 7/8/14, 4:32 PM, Fabio Maino wrote: > On 7/7/14, 5:27 PM, Marc Binderberger wrote: ... >> 4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say >> >> When the P bit is set, the N, E, and V bits MUST be set to zero. The >> receiving (legacy) LISP router will ignore N, E and V bits, when the >> P bit is set. >> >> I would think a receiving legacy LISP router has no idea about the P bit, >> which is why you explicitly set N/E/V to zero? > > Right. Per LISP specification P bit is ignored, and given that NEV are > set to zero, the next protocol field is ignored too. We'll rephrase the > sentence to make it more clear. From nobody Tue Jul 8 17:08:32 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99241A0194 for ; Tue, 8 Jul 2014 17:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vHZ5enb6HJh for ; Tue, 8 Jul 2014 17:08:27 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF391A0190 for ; Tue, 8 Jul 2014 17:08:27 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id ey11so8186001pad.12 for ; Tue, 08 Jul 2014 17:08:27 -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=uAV+pVNi/NAUZAvs8+84JvwJc1m9e7v++dNEuyXxQrU=; b=bcwcWRQmM/3pM3CX+UjEAc1bQ96+ibyQ0wBI18hLKsjtX50qq/ifz1FNEcFxivpPoz UYmQf8XyOJq1cW97h98gWwgE0v9bR0IrqIG6Ss2Dkzn168RdHva3rY1Q1rdnhTawyDkM 8IZsh6oraX5XyHJB9D+CQDb9HFehGLKpUS4EW7/PTOiWfJz/puaYefrqDKoyVZY7Nauw z6beiXe3xv2U+RItfDRvnJ8nM0/+KbkBOE0SgNuP3MPPw6xrdkLuw8/xdlFDMTUE4eYq TDjDKHITQqDyDDBueJ5zpfIG5390M4nwask5jQATbjfhvMFrUvHgF+g0vTzO806s2HVW /qVA== X-Received: by 10.70.118.5 with SMTP id ki5mr8130655pdb.104.1404864507555; Tue, 08 Jul 2014 17:08:27 -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 sv10sm208734495pab.32.2014.07.08.17.08.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 17:08:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <53BC86FF.4010906@joelhalpern.com> Date: Tue, 8 Jul 2014 17:08:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <79CB3FF2-BC7B-4F99-A577-271FE3290171@gmail.com> References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> <53BC86FF.4010906@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Pm7E1iTiKORUZsURbi9JeauStyQ Cc: lisp@ietf.org, Puneet Agarwal , nyadav@cisco.com, Larry Kreeger , "Michael Smith \(michsmit\)" Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:08:30 -0000 > I am very concerned about the compatibility behavior of this. > If the sender is setting the P bit, and the next header, then he = presumably thinks that is useful to the receiver. If the receiver is = ignoring the P bit, and ignoring the field occupied by the next-header, = how will the receiver know what the content is? Are we assuming that = the sender will magically know what packet type the receiver expects, = even though the sender is capable of sending several different packet = types? I made this comment to the co-authors of the draft. I suggested the best = way to handle this is for an ETR to indicate in its RLOC record it = registers to the mapping system, what format it can parse. Again, you = know where I'm going with this but don't want to say so. LOL. > I am also concerned that this is removing several features that the = working group has, up till now, deemed important. If this gpe is = important, then we will have to ensure that we do not count on any of = those features for reliable operation. If that is our intent, then the = document really needs to say so explicitly so that WG adoption actually = represents agreement to those constraints. Agree. Dino >=20 > Yours, > Joel >=20 > On 7/8/14, 4:32 PM, Fabio Maino wrote: >> On 7/7/14, 5:27 PM, Marc Binderberger wrote: > ... >>> 4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say >>>=20 >>> When the P bit is set, the N, E, and V bits MUST be set to zero. = The >>> receiving (legacy) LISP router will ignore N, E and V bits, when = the >>> P bit is set. >>>=20 >>> I would think a receiving legacy LISP router has no idea about the P = bit, >>> which is why you explicitly set N/E/V to zero? >>=20 >> Right. Per LISP specification P bit is ignored, and given that NEV = are >> set to zero, the next protocol field is ignored too. We'll rephrase = the >> sentence to make it more clear. >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Jul 8 17:18:48 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776FD1A019A for ; Tue, 8 Jul 2014 17:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHrS1opqs8gx for ; Tue, 8 Jul 2014 17:18:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385891A0194 for ; Tue, 8 Jul 2014 17:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1251; q=dns/txt; s=iport; t=1404865126; x=1406074726; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1M4cXryjNDsRDACiSuKosHM3Mh5yEfp+w+ptqs9oJDI=; b=IZGuzM3N5cqdgo5FDUNXbDjcR4Z2H3wx3M1T70j5gNPSROJb40OrmWao CWHNG2OMy4E+6pDzJZ36ECL9jlJjQeIbV3gLl2AZdWYs83APLhoEHii/l g5YePC5usZXA6MBRMYG/s+JaTi/nPrCdASNNS49KtB09bLw0bRNWEUWJM U=; X-IronPort-AV: E=Sophos;i="5.01,629,1400025600"; d="scan'208";a="59297192" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 09 Jul 2014 00:18:45 +0000 Received: from [10.154.212.111] ([10.154.212.111]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s690Iibp016434; Wed, 9 Jul 2014 00:18:45 GMT Message-ID: <53BC8A77.3090909@cisco.com> Date: Tue, 08 Jul 2014 17:19:03 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> <7FAB93E6-780E-4C92-A791-4B514FF2770E@gmail.com> In-Reply-To: <7FAB93E6-780E-4C92-A791-4B514FF2770E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/nFnTw7Imz5Gqlu4823XDXe_er6Q Cc: lisp@ietf.org, Puneet Agarwal , nyadav@cisco.com, Larry Kreeger , "Michael Smith \(michsmit\)" Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:18:47 -0000 Dino, I thought that lisp-crypto was overlapping with the use of P bit already. My mistake: I see that the picture in the lisp-crypto draft mentions indeed the P bit. I think what GPE is trying to propose, is an extension to the LISP protocol that together with crypto would allow LISP to handle a set of "features": multiprotocol, services, metadata... IMO, if we have to change the data path, we should rather look at a change that enables a set of "features" rather than a single one. Fabio On 7/8/14, 1:39 PM, Dino Farinacci wrote: >>> 2) the layout does not fit well with draft-farinacci-lisp-crypto-00. Are >>> there any plans to solve this? Should this at least be mentioned somewhere? >> >> Both this draft and lisp-crypto are proposals to extend the LISP encap with new features. I don't think they need to refer each other at this point. >> >> I just note that by adding multiprotocol support, one could add a shim header that provides encryption services to the LISP payload. > When I selected the location of the K bits, I knew the P-bit was predefined in the gpe draft, so I didn't use that location. There are no flag bits left if GPE and lisp-crypto are accepted as working group items. > > Dino > From nobody Tue Jul 8 17:24:32 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD71A019B for ; Tue, 8 Jul 2014 17:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4U4KJXi38nY for ; Tue, 8 Jul 2014 17:24:29 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3421F1A0196 for ; Tue, 8 Jul 2014 17:24:29 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id fp1so8015793pdb.2 for ; Tue, 08 Jul 2014 17:24: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=DyWpSLJN0nySn/kmPZ9+YUs9t4SMg/bITn6cKWHcoQo=; b=uN9fuZsVHAiI0kXqp+BZMH+KvoxDWlehdKWXwDUXdp20w+EBsFGI2zRCVWIwGsIqnY 9wa0Ea9TBLtXwIvV3IjzCZfo6u6SbSMjBfQXviaFVpjKT9XSRjcg9et8jENazO6Kwp3m 4I5mjLd9kLY23eNpeUTnHJAzJYoisf8TZdqTK7RAX1OJK50HGQAKRwMZQq3gZW9Y/uK1 N7nipyaY2YhRhb51K2H/DugDAxXSngG+jA6T280gSYnnFhnLqkkoosVqAUXC2C/cxXjS Z9Du6a57S2YezO9YkxLBgAnoGEReORlOo2gaep5soylXonYf8ZPFBCzvcZZtQp0d4+YO 2nTQ== X-Received: by 10.70.43.43 with SMTP id t11mr8066924pdl.49.1404865468869; Tue, 08 Jul 2014 17:24:28 -0700 (PDT) Received: from [192.168.1.82] ([207.145.253.66]) by mx.google.com with ESMTPSA id gq4sm56966082pbc.64.2014.07.08.17.24.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 17:24:28 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <53BC8A77.3090909@cisco.com> Date: Tue, 8 Jul 2014 17:23:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> <7FAB93E6-780E-4C92-A791-4B514FF2770E@gmail.com> <53BC8A77.3090909@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/iDybXOQxebhX-nCsGmHbN6153tU Cc: lisp@ietf.org, Puneet Agarwal , nyadav@cisco.com, Larry Kreeger , "Michael Smith \(michsmit\)" Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:24:31 -0000 > Dino, > I thought that lisp-crypto was overlapping with the use of P bit = already. My mistake: I see that the picture in the lisp-crypto draft = mentions indeed the P bit. Not sure why I would want to do that. I would like all designs to play = together nicely and not look like they were done in silos. > I think what GPE is trying to propose, is an extension to the LISP = protocol that together with crypto would allow LISP to handle a set of = "features": multiprotocol, services, metadata... IMO, if we have to = change the data path, we should rather look at a change that enables a = set of "features" rather than a single one. Yes, if they can be added at the same time. But typically has happened = and we have seen this with LISP since 2007 that features get added over = time in subsequent generation products. And I have been put on record = many times for not changing the data plane. IMO, the P-bit is a change that doesn't really add anything new but does = something for another data-plane. That probably does not have a good = cost/benefit tradeoff.=20 Howver, service chaining is a completely different matter. Dino >=20 > Fabio >=20 >=20 >=20 > On 7/8/14, 1:39 PM, Dino Farinacci wrote: >>>> 2) the layout does not fit well with = draft-farinacci-lisp-crypto-00. Are >>>> there any plans to solve this? Should this at least be mentioned = somewhere? >>>=20 >>> Both this draft and lisp-crypto are proposals to extend the LISP = encap with new features. I don't think they need to refer each other at = this point. >>>=20 >>> I just note that by adding multiprotocol support, one could add a = shim header that provides encryption services to the LISP payload. >> When I selected the location of the K bits, I knew the P-bit was = predefined in the gpe draft, so I didn't use that location. There are no = flag bits left if GPE and lisp-crypto are accepted as working group = items. >>=20 >> Dino >>=20 >=20 From nobody Tue Jul 8 17:45:26 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A981A01BD for ; Tue, 8 Jul 2014 17:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRhMVlDI4zp9 for ; Tue, 8 Jul 2014 17:45:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D73E1A01A7 for ; Tue, 8 Jul 2014 17:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2430; q=dns/txt; s=iport; t=1404866733; x=1406076333; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UQhoXXRpU1/WOHzSKVq6GnJRkAft7DrJYlKjYP+kfZU=; b=fBKjY4D8d/4RGNp3gBSKscKdiBqGxVMyehYylVSfxlAMOquJ3XGqa6/C arirJAKqWGHXY+GDRUuoqWCq1HBrKkZy+dmdkDzUXdmhDGD26FSrSAveZ au+hMP5TSOx/a5OU8+Om4Ug+ePN0wgIer/Gy0BmbTjG6ujiLtgjLXo26r M=; X-IronPort-AV: E=Sophos;i="5.01,629,1400025600"; d="scan'208";a="338652632" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jul 2014 00:45:32 +0000 Received: from [10.154.212.111] ([10.154.212.111]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s690jMOk013907; Wed, 9 Jul 2014 00:45:22 GMT Message-ID: <53BC90B5.6070609@cisco.com> Date: Tue, 08 Jul 2014 17:45:41 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Marc Binderberger , Darrel Lewis , pagarwal@broadcom.com, kreeger@cisco.com, paulq@cisco.com, michsmit@cisco.com, nyadav@cisco.com References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> <53BC86FF.4010906@joelhalpern.com> In-Reply-To: <53BC86FF.4010906@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/FYsWgNetrgL_bVY1ag0hDCFob38 Cc: lisp@ietf.org Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:45:25 -0000 On 7/8/14, 5:04 PM, Joel M. Halpern wrote: > I am very concerned about the compatibility behavior of this. > If the sender is setting the P bit, and the next header, then he > presumably thinks that is useful to the receiver. No. the draft is just suggesting that a GPE implementation can take advantage of how LISP is specified and send a GPE encapsulated packet (with an IPvX payload) to a LISP receiver. There are no assumption made on the receiver behavior, excpet than it should be a LISP device. > If the receiver is ignoring the P bit, and ignoring the field occupied > by the next-header, how will the receiver know what the content is? > Are we assuming that the sender will magically know what packet type > the receiver expects, even though the sender is capable of sending > several different packet types? that information could come from the mapping system. > > I am also concerned that this is removing several features that the > working group has, up till now, deemed important. If this gpe is > important, then we will have to ensure that we do not count on any of > those features for reliable operation. If that is our intent, then > the document really needs to say so explicitly so that WG adoption > actually represents agreement to those constraints. > Fair comment, we'll add text trying to capture this. I personally think that it would be a reasonable trade off to give those features up in exchange of adding support for multiprotocol, OAM and explicit service tagging. If the group wishes to do so, I think that the flexibility added by GPE would allow to reintroduce some or all of those features. Fabio > Yours, > Joel > > On 7/8/14, 4:32 PM, Fabio Maino wrote: >> On 7/7/14, 5:27 PM, Marc Binderberger wrote: > ... >>> 4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say >>> >>> When the P bit is set, the N, E, and V bits MUST be set to >>> zero. The >>> receiving (legacy) LISP router will ignore N, E and V bits, when >>> the >>> P bit is set. >>> >>> I would think a receiving legacy LISP router has no idea about the P >>> bit, >>> which is why you explicitly set N/E/V to zero? >> >> Right. Per LISP specification P bit is ignored, and given that NEV are >> set to zero, the next protocol field is ignored too. We'll rephrase the >> sentence to make it more clear. From nobody Wed Jul 9 11:24:32 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB561A0B17 for ; Wed, 9 Jul 2014 11:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmzoNgP8aHOB for ; Wed, 9 Jul 2014 11:24:27 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F215F1A0379 for ; Wed, 9 Jul 2014 11:24:26 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 468082AA0F; Wed, 9 Jul 2014 18:24:21 +0000 (GMT) Date: Wed, 9 Jul 2014 11:24:20 -0700 From: Marc Binderberger To: "Joel M. Halpern" Message-ID: <20140709112420738267.ef5a22d2@sniff.de> In-Reply-To: <53BC86FF.4010906@joelhalpern.com> References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> <53BC86FF.4010906@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/yiMkKk14PpeExnSvUzMuSo7EoLk Cc: lisp@ietf.org, pagarwal@broadcom.com, nyadav@cisco.com, kreeger@cisco.com, michsmit@cisco.com Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 18:24:30 -0000 Hello Joel, > I am also concerned that this is removing several features that the working > group has, up till now, deemed important. I'm not sure I understand this comment. You mean the collision with draft-farinacci-lisp-crypto-00 ? (and other drafts which I may have missed) Or do you mean that N/E/V must be zero when P=1 ? How is this different from e.g. N/E must be zero when V=1 ? Regards, Marc On Tue, 08 Jul 2014 20:04:15 -0400, Joel M. Halpern wrote: > I am very concerned about the compatibility behavior of this. > If the sender is setting the P bit, and the next header, then he presumably > thinks that is useful to the receiver. If the receiver is ignoring the P > bit, and ignoring the field occupied by the next-header, how will the > receiver know what the content is? Are we assuming that the sender will > magically know what packet type the receiver expects, even though the > sender is capable of sending several different packet types? > > I am also concerned that this is removing several features that the working > group has, up till now, deemed important. If this gpe is important, then > we will have to ensure that we do not count on any of those features for > reliable operation. If that is our intent, then the document really needs > to say so explicitly so that WG adoption actually represents agreement to > those constraints. > > Yours, > Joel From nobody Wed Jul 9 12:35:38 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC861A0417 for ; Wed, 9 Jul 2014 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMAPOtxRHhk3 for ; Wed, 9 Jul 2014 12:35:34 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59561A0415 for ; Wed, 9 Jul 2014 12:35:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 2BFF752126A; Wed, 9 Jul 2014 12:35:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 20BC2521268; Wed, 9 Jul 2014 12:35:32 -0700 (PDT) Message-ID: <53BD9983.8080707@joelhalpern.com> Date: Wed, 09 Jul 2014 15:35:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marc Binderberger References: <20140704194506.3562.56817.idtracker@ietfa.amsl.com> <20140707172727580331.8446565a@sniff.de> <53BC5569.4000002@cisco.com> <53BC86FF.4010906@joelhalpern.com> <20140709112420738267.ef5a22d2@sniff.de> In-Reply-To: <20140709112420738267.ef5a22d2@sniff.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/qXBgJFVTgrPg_PhcV7JWqZUkTGM Cc: lisp@ietf.org, pagarwal@broadcom.com, nyadav@cisco.com, kreeger@cisco.com, michsmit@cisco.com Subject: Re: [lisp] draft-lewis-lisp-gpe-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:35:36 -0000 I am refering to the issue that N/E/V must be zero. This is different from N/E must be zero when V is one for two reasons. The important reason, and the only reason that the WG needs to address, is that the existing document explains what features are lost when you do that. The other reason is that the N/E/V bits are essentially alternative mechanisms for addressing related problems. The P bit is for a very different problem. I have seen confirmation on the list from the authros taht they are happy to put in the explicit text. After that, I leave it to the rest of the WG whether the tradeoff is one they want to make. Yours, Joel On 7/9/14, 2:24 PM, Marc Binderberger wrote: > Hello Joel, > >> I am also concerned that this is removing several features that the working >> group has, up till now, deemed important. > > I'm not sure I understand this comment. You mean the collision with > draft-farinacci-lisp-crypto-00 ? (and other drafts which I may have missed) > > Or do you mean that N/E/V must be zero when P=1 ? How is this different from > e.g. N/E must be zero when V=1 ? > > > Regards, Marc > > > On Tue, 08 Jul 2014 20:04:15 -0400, Joel M. Halpern wrote: >> I am very concerned about the compatibility behavior of this. >> If the sender is setting the P bit, and the next header, then he presumably >> thinks that is useful to the receiver. If the receiver is ignoring the P >> bit, and ignoring the field occupied by the next-header, how will the >> receiver know what the content is? Are we assuming that the sender will >> magically know what packet type the receiver expects, even though the >> sender is capable of sending several different packet types? >> >> I am also concerned that this is removing several features that the working >> group has, up till now, deemed important. If this gpe is important, then >> we will have to ensure that we do not count on any of those features for >> reliable operation. If that is our intent, then the document really needs >> to say so explicitly so that WG adoption actually represents agreement to >> those constraints. >> >> Yours, >> Joel From nobody Wed Jul 16 02:49:47 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EE81A059F for ; Wed, 16 Jul 2014 02:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGeWtsugshdI for ; Wed, 16 Jul 2014 02:49:42 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0DE1A0376 for ; Wed, 16 Jul 2014 02:49:42 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so959643wiv.13 for ; Wed, 16 Jul 2014 02:49:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=+l5PtzizNFOvmTzV8VGE6RgOIXg6m1uXZ9O+tJw9YRM=; b=SFY7TUjWjmOLgzKu9decdVIRRuvycwd3yoyLmy/mBJt8Lz/IhTfgHnrjhwVqzgFd5v n3az5uuzFq5QAskBxYOTERi4eMipNs403Lj2j8hNmNVqakVwT3BW+xd6Hl0Ffs5GbO61 6oslpH5q8d3aXQnmfq6N8h0B2hd6aQ4XTpHpPWmoKVwxiOdD+/3eqsJD9Nd1htJ3exVi vqPhFpHEHSVUh2cqQ9wnC/zlxVUGfOAiUWsrixuY6ONNr55QzhidKRceJNkapxE5HgyW glMLBCo8migj+c9we0vbZwZ0TNbOOwJR4xhftRGRcB+GQbNtHtLLShup1zngqZmWGgIb CTBw== X-Gm-Message-State: ALoCoQkfzkIkCY396vBvDssqA1t0PRUZC5xlLk9wXg+E2OPw2AgWXsG8TTzDa+1PpBu7sKB4iE97 X-Received: by 10.180.100.200 with SMTP id fa8mr11943020wib.23.1405504176825; Wed, 16 Jul 2014 02:49:36 -0700 (PDT) Received: from dhcp164-99.enst.fr (dhcp164-99.enst.fr. [137.194.165.99]) by mx.google.com with ESMTPSA id ft6sm14052382wic.0.2014.07.16.02.49.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 02:49:35 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_036C019D-B1BB-48AF-AC25-209C42961204" Date: Wed, 16 Jul 2014 11:49:34 +0200 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/-Fk5Urg4vdOs-N1GmyIR9F95tKI Cc: lisp-chairs@tools.ietf.org Subject: [lisp] LISP Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 09:49:43 -0000 --Apple-Mail=_036C019D-B1BB-48AF-AC25-209C42961204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, hereafter the final agenda for the LISP WG session. To all presenter please send your slides to the chairs by 13:00 = Wednesday 23th July so that we have time to upload them. =20 See you next week in Toronto. ciao Luigi CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Terry Manderson ( Terry.Manderson AT icann.org ) Luigi Iannone ( ggx AT gigix.net ) SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) Damien Saucez ( damien.saucez AT gmail.com ) AGENDA Session 1/1 (60 min) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- THURSDAY, July 24, 2014 1730-1830, 60 Mins Administration 5 minutes=20 Halpern/Manderson/Iannone - Blue Sheets - Co-Chairs Composition - Agenda Bashing - Status reports for WG drafts o WG Documents update - LISP Introduction 10 minutes Chairs/D. Saucez/A. Cabellos - LISP Threats Analysis http://tools.ietf.org/wg/lisp/draft-ietf-lisp-threats 15 minutes D. Saucez - LISP EID Block Management=20 http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt 5 min L. Iannone o Non WG Documents - LISP OAM (Operation Administration Management) http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00 10 mins A. Cabellos - LISP Data-Plane Confidentiality=20 http://tools.ietf.org/html/draft-farinacci-lisp-crypto 10 mins D. Farinacci - LISP Generic Protocol Extension=20 http://tools.ietf.org/html/draft-lewis-lisp-gpe 5 mins D. Lewis= --Apple-Mail=_036C019D-B1BB-48AF-AC25-209C42961204 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

hereafter the final agenda for the LISP WG = session.

To all presenter please send your = slides to the chairs by 13:00 Wednesday 23th July so that we have = time to upload them.

See you next week in = Toronto.

ciao

Luigi

CHAIR(s): Joel Halpern ( jmh = AT joelhalpern.com )
  =         Terry Manderson ( = Terry.Manderson AT icann.org )
=    Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Wassim = Haddad ( wassim.haddad AT ericsson.com )
   =        Damien Saucez ( damien.saucez = AT gmail.com )

AGENDA

Se= ssion 1/1 (60 min)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

THURSDAY= , July 24, 2014
1730-1830, 60 Mins

Administration =        5 = minutes
   Halpern/Manderson/Iannone
&nbs= p; - Blue Sheets
   - Co-Chairs = Composition
   - Agenda Bashing
   - = Status reports for WG drafts

o WG Documents update

- = LISP Introduction
10 minutes
Chairs/D. Saucez/A. = Cabellos

- LISP Threats Analysis
http://tool= s.ietf.org/wg/lisp/draft-ietf-lisp-threats
15 = minutes
= D. Saucez

- LISP EID Block Management
http:/= /tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt
5 = min
= L. Iannone

o Non WG Documents

- LISP OAM = (Operation Administration Management)
http:= //tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00
10 = mins
= A. Cabellos

- LISP Data-Plane = Confidentiality
http://too= ls.ietf.org/html/draft-farinacci-lisp-crypto
10 = mins
= D. Farinacci

- LISP Generic Protocol = Extension
http://tools.ietf= .org/html/draft-lewis-lisp-gpe
5 mins
D. = Lewis

= --Apple-Mail=_036C019D-B1BB-48AF-AC25-209C42961204-- From nobody Wed Jul 16 08:02:14 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58DF1B2B8A; Wed, 16 Jul 2014 08:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k8DNAMWs3YT; Wed, 16 Jul 2014 08:01:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8963A1B2AC9; Wed, 16 Jul 2014 08:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140716150142.29237.64801.idtracker@ietfa.amsl.com> Date: Wed, 16 Jul 2014 08:01:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/MqZHjD241ruQD-WLvo4S_BXPdGE Cc: lisp@ietf.org Subject: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 15:01:52 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the LISP Location-Identity Separation System Author(s) : J. Chiappa Filename : draft-ietf-lisp-introduction Pages : 59 Date : 2014-07-16 This document is an introductory overview of the Locator/ID Separation Protocol, it describes the major concepts and functional sub-systems of LISP and the interactions between them. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-introduction"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-16080142.I-D@ietf.org> --NextPart-- From nobody Wed Jul 16 09:40:47 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B632E1A0051; Wed, 16 Jul 2014 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hVtDeWsOUmt; Wed, 16 Jul 2014 09:40:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFFA1A0048; Wed, 16 Jul 2014 09:40:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> Date: Wed, 16 Jul 2014 09:40:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/oY45aEoWG6-b78G0d8T1y3bNb50 Cc: lisp@ietf.org Subject: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:40:44 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the LISP Location-Identity Separation System Author(s) : D. Saucez, et al Filename : draft-ietf-lisp-introduction Pages : 59 Date : 2014-07-16 This document is an introductory overview of the Locator/ID Separation Protocol, it describes the major concepts and functional sub-systems of LISP and the interactions between them. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-introduction"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-16094043.I-D@ietf.org> --NextPart-- From nobody Wed Jul 16 09:47:45 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C266D1A007A for ; Wed, 16 Jul 2014 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnHcUMKD2Df2 for ; Wed, 16 Jul 2014 09:47:42 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906311A0073 for ; Wed, 16 Jul 2014 09:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 12555D4565B for ; Wed, 16 Jul 2014 09:47:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id AB52DD406A8 for ; Wed, 16 Jul 2014 09:47:41 -0700 (PDT) Message-ID: <53C6ACAC.7090407@joelhalpern.com> Date: Wed, 16 Jul 2014 12:47:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "lisp@ietf.org" References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> In-Reply-To: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------010303070905070307010209" Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/L7eSzgyWPO-dBTDvdaLdOMT6FbA Subject: [lisp] Fwd: I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:47:44 -0000 This is a multi-part message in MIME format. --------------010303070905070307010209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The chairs and listed authors are happy to call the WGs attention to the latest revision of the LISP Introduction draft. If you can take a look at this before the meeting in Toronto, that would be good. Our apologies for the late notice. Yours, Joel -------- Original Message -------- Subject: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt Date: Wed, 16 Jul 2014 09:40:43 -0700 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the LISP Location-Identity Separation System Author(s) : D. Saucez, et al Filename : draft-ietf-lisp-introduction Pages : 59 Date : 2014-07-16 This document is an introductory overview of the Locator/ID Separation Protocol, it describes the major concepts and functional sub-systems of LISP and the interactions between them. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------010303070905070307010209 Content-Type: Message/External-body; name="draft-ietf-lisp-introduction" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-introduction" Content-Type: text/plain Content-ID: <2014-07-16094043.I-D@ietf.org> --------------010303070905070307010209 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --------------010303070905070307010209-- From nobody Wed Jul 16 12:56:43 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0881A0204 for ; Wed, 16 Jul 2014 12:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpErpf5vtBtP for ; Wed, 16 Jul 2014 12:56:37 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EFF1A0218 for ; Wed, 16 Jul 2014 12:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2275; q=dns/txt; s=iport; t=1405540580; x=1406750180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3YfYlv4MObQMcbSoXnD7NmDPGwCV32QRGAj8UdmpHRw=; b=Buu8p3ozjSxUZ21WhGSIGhrTpJM94RZ1CiAfiaMu+Je6gkH/lI23fJco tje0NutF8hdpw/gUPIHKNq6VmyJ2xvnhkbbCLcXJIfId1VkbV3p0jJsP4 TpV9WUrMq8i/KK0rb8kUiMmu0gCjQMTE+Cd4I0jKjiOge+HqVacFkCBzW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAGnYxlOtJA2N/2dsb2JhbABQCYMOUlcEwygMh0ABgQkWdoQDAQEBAwEBAQFrCwUHBAIBCBEDAQIvJwsdCAIEDgWIOggNylATBI5wCgEBHAgrBwaDJ4EWAQSbHZQsg0RsAYELOQ X-IronPort-AV: E=Sophos;i="5.01,673,1400025600"; d="scan'208";a="61404271" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 16 Jul 2014 19:56:19 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6GJuJ9W021688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 19:56:19 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 14:56:19 -0500 From: "Darrel Lewis (darlewis)" To: "Joel M. Halpern" Thread-Topic: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt Thread-Index: AQHPoTACpDDsmmAC7UGs2qycW0/oCg== Date: Wed, 16 Jul 2014 19:56:18 +0000 Message-ID: References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> In-Reply-To: <53C6ACAC.7090407@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.0.42] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/wWCl8ZrZn3SYqXZMaUA8sEko6VM Cc: "lisp@ietf.org" Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 19:56:39 -0000 On Jul 16, 2014, at 9:47 AM, Joel M. Halpern wrote: > The chairs and listed authors are happy to call the WGs attention to the = latest revision of the LISP Introduction draft. > If you can take a look at this before the meeting in Toronto, that would = be good. > Our apologies for the late notice. >=20 > Yours, > Joel >=20 >=20 Joel, Editors; This document contains many recommendations by the editors in bracketed for= m. Are the editors looking for a review focused on accepting/rejecting the= se comments? FWIW at a quick read I=92d be willing to accept all (or nearly all) of the = editors suggestions. I will happily review the document either in its enti= rety or focus on the editorial comments, or both. -Darrel > -------- Original Message -------- > Subject: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt > Date: Wed, 16 Jul 2014 09:40:43 -0700 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: lisp@ietf.org >=20 > A new Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Locator/ID Separation Protocol Working G= roup of the IETF. >=20 > Title : An Architectural Introduction to the LISP Location-Ide= ntity Separation System > Author(s) : D. Saucez, et al > Filename : draft-ietf-lisp-introduction > Pages : 59 > Date : 2014-07-16 >=20 > This document is an introductory overview of the Locator/ID > Separation Protocol, it describes the major concepts and functional > sub-systems of LISP and the interactions between them. >=20 >=20 > A URL for this Internet-Draft is: > https://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 > ________________= _______________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jul 17 01:11:00 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0788B1A002C for ; Thu, 17 Jul 2014 01:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDip3N-PwMOX for ; Thu, 17 Jul 2014 01:10:48 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D31A0031 for ; Thu, 17 Jul 2014 01:10:47 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so2044155wes.32 for ; Thu, 17 Jul 2014 01:10:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=BhppxNdXgTVI4EBhPii6iUh+o3N3GouP4+pdBHgDOmk=; b=WTIc4eUYizGlGiM52FoGkcr0v0rAFRge+cPyu6iWwSaoClXHCUeJg3hvNQNRmP/rZE l/uiVeG+k+Cp8ceTS3yJlswAHvFdxaM9lEomjU319ZBPak2mZX7mh+v7A4qDQME1hze+ 4Us0Mi4rGo1l/FFciJrCT56fqdd84Tk+o3TCmhh/4UKic1NaZOQ3LsAoJTnHJB21oZz4 JLVxGc8VTef5/dYo6MGl1x9kdspDHUilF6xX6axVvV/ZQiWGC/Q8JWJVKcMNwXXZ04cR pZpI1DQmVQB/ERgOCJMCZlmCpxgacMeVJuI6E6//3m3USvlSP3V63sGFXo38syhdaveV uq/w== X-Gm-Message-State: ALoCoQmJ5C1haLYIpEWmsGgLDAnaTfjuuLK2DrvqEd88jlZ8u4AEo8zi+CqL/Y4Bua54MqrvIMb3 X-Received: by 10.180.228.104 with SMTP id sh8mr20214363wic.64.1405584639521; Thu, 17 Jul 2014 01:10:39 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:9007:ad41:b24f:f0b4? ([2001:660:330f:a4:9007:ad41:b24f:f0b4]) by mx.google.com with ESMTPSA id lo18sm18435902wic.1.2014.07.17.01.10.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 01:10:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_14FBE219-3C4B-4BEC-B1E7-04B63C6D87FE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Luigi Iannone In-Reply-To:

--001a11c2f68231645c04fe6a223e-- From nobody Thu Jul 17 14:19:17 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A081A0205 for ; Thu, 17 Jul 2014 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Bbr5R7bzMZy for ; Thu, 17 Jul 2014 14:19:14 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0931A02D5 for ; Thu, 17 Jul 2014 14:19:14 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so4082813pab.40 for ; Thu, 17 Jul 2014 14:19:14 -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=mZ82fqtN468afBS2Pw0SJcSLLldoGeaFG9XvRGfDWNM=; b=w4w1ImM0pIBEuwQUvoMlLWPl1XCHPSF8LW+LIC3Qtqa7sz+WjQh9YNChmmVKtcAm3G HMMd4hCBVabnPpN9Xf9yWtRpkk5scqA+Yi8e3uLvNTZ9A76Cxcx8mv6tmfLnZSEqXK/L wJLn4MHXJeG8y6h5GryvqDSeLcsK5a6v7KkMr9BusnPBhQb3iTzei5DVKB/EPB8GLEKH 2dXqNZrXnB5nkvzwmqavSo/MN8TBiu14x9e1rKoJE0h8QgfCkLr13GQZsu2KLy9hts0r CxA6cXG0o4zD/wwyVAEAeG/w8veKHcnAR30+JfbrVJpRg9jBzyepMxdK4w/q2NIs9AJv CsUg== X-Received: by 10.70.127.163 with SMTP id nh3mr21174288pdb.139.1405631954202; Thu, 17 Jul 2014 14:19:14 -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 x5sm3465653pbw.26.2014.07.17.14.19.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 14:19:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Thu, 17 Jul 2014 14:19:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References:

To: DaeYoung KIM X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/txCnMYqIPmbs-evNjFOTvjn1amQ Cc: lisp Subject: Re: [lisp] Q: draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:19:15 -0000 DY and I are going private. If anyone wants a summary of this discussion = DY will provide one. Dino On Jul 17, 2014, at 2:14 PM, DaeYoung KIM wrote: > On Thu, Jul 17, 2014 at 10:33 PM, Dino Farinacci = wrote: >=20 > > On Thu, Jul 17, 2014 at 10:03 PM, Dino Farinacci = wrote: > > But when an EID is assigned to a node (either static or via DHCP) > > > > Is there a case in LISP that EID would be assigned to its interface = rather than to a node? >=20 > That is independent of LISP. >=20 > Yes, in principle. But if you'd maintain the assertion (if such an = assertion has ever been made) that the network elements within a site = doesn't change, it would automatically assumed that >=20 > - nodes in a site maintains the IP address (already) assigned, and > - the IP addresses would have been assigned to the interfaces. >=20 > And a node can have multiple EIDs if one chooses to do that. In fact, = a dual-stack host will have two EIDs, one IPv4 and one IPv6. >=20 > This multiple EIDs for a node is not my immediate concern in this = discussion. I'm try to confine myself to the most basic model of LISP, = in order better to understand it. > =20 > > Somewhere, it is said that the behavior of network elements within a = site doesn't change, which is thought to be one of the major strong = feature of LISP. If that is the case, then the EID would be assigned to = the interface like with the current Internet. >=20 > Right, there are no requirements how EIDs are assigned locally within = a system. Remember, the EID is on a unchanged host. =46rom that host's = point of view, it is just an address. =46rom the LISP site's point of = view, that address is reachable via local routing. >=20 > This means... (if an EID is assigned to an interface)... the e2e = transport connection would break if a node move from one subnet to = another within a site. LISP doesn't contribute to solving/improving the = intra-site mobility. Right? >=20 > > Assuming you really meant the node, not the interface, which = existing mechanism would allow the mobility? OSPF or ISIS? >=20 > What I meant is the "IP address" is moving. Saying it that way means = no matter how it is assigned on the local device, what is moving is the = IP address. >=20 > I'm still in the same hole. Does this IP address change when a node = moves from one subnet to another or not? > =20 > > If you meant, in fact, the interface but not the node in your = discussion of the EID assignment, do you mean a MIP like mechanism would = provide the mobility within a site? >=20 > I didn't and don't need to make that distinction. >=20 > So, you don't care about the intra-site problems at all. You focus on = the inter-site routing, don't you? >=20 > The whole idea of LIS(locator/id separation) is to solve, among many = things, the mobility problem. To ensure that, an ID would be kept = constant at moving of a node while locator would be updated at every = such moving. Am I correct? >=20 > However, if behavior of the all network elements within a site doesn't = have to change, as asserted somewhere in the main documents, (this would = mean that ARP is also at work as usual), the ID (in fact, the IP = address) would change at any such moving, which would not keep the EID = constant. Such move would not only break a intra-site connection but = also a connection between sites. >=20 > So, you cannot just ignore the intra-site problems. If the EID(IP = address) has to change at every node moving across subnets within a = site, the whole purpose of ID (in LIS) would be questioned. Isn't this = in contradiction to the whole idea of LIS? >=20 > If the EID would be kept constant even at moving within a site, then = some network elements within a site have to change their behavior, don't = they? Even the host behavior might have to change like, for example, = shutting off the ARP operation. >=20 > Also, EIDs can be flat, as with other usual LIS proposals, and need = not necessarily be out of a power-of-2 EID prefix. Correct? >=20 > > So in the static case, that would mean a host route would need to be = injected into the IGP if the node's address stays the same > > > > I cannot catch what you exactly mean here by 'injection'. Sorry... >=20 > When a host 10.1.1.1 moves off subnet 10.1.0.0/16 to subnet = 11.1.0.0/16, the routers attached to 11.1 need to advertise a = 10.1.1.1/32 route into the routing system. >=20 > Got it. This is exactly what ISIS is doing, right? >=20 > > So, in short, what mobility solution is provided by LISP in addition = to the existing mobility mechanisms? >=20 > There are different scopes of mobility. When you roam across LISP = site, you use LISP mobility. >=20 > You mean the tunneling..? Tunneling implicitly provides some sort of = mobility... like that? > =20 > When you roam within LISP sites you use IP-mobility or host routes.=20 >=20 > So, no additional contribution by LISP as far as intra-site mobility = is concerned. Right?=20 >=20 > --=20 > DY From nobody Thu Jul 17 14:32:26 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF591A020B for ; Thu, 17 Jul 2014 14:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvBAKbf9m-eW for ; Thu, 17 Jul 2014 14:32:23 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA211A028B for ; Thu, 17 Jul 2014 14:32:22 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id g18so1671093oah.23 for ; Thu, 17 Jul 2014 14:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=u5ckYThqZok1LjzG6XunHWoSTThC3navZ/GgVopXTkE=; b=hxgxHXnd9z3a8kEghvSM/yrxyfgFbYaisCjRYPTbYo6p6CX69WcO9MsjNCZuIf4bYW Y5d9PrmUxQ6suc1PEqfPUyDEfyUVp5CU2xzYyipmHgoHCjeI5ekQpxxEc+5Wv/wshjSU OyYBGmjA2ZUAQ9VWXbOli+Um06zWst+tkjZgHzRShspgK/N6k4hZzUP0AZENvLnsTiE7 9gK2EXPZr3UAEMI7inD30kJP/8bwuHm6rJ1DQ0eX3ymmIB8AKFFvhg0TS0obsyY7V2Bj ZQQHTsW7IokB7laNoroFIpxDEoKCSxSCekeJNPXQpbIZNKa0T0h2t0qFg5tUCYHpVKmw 0wcw== X-Received: by 10.60.47.77 with SMTP id b13mr8386964oen.83.1405632742207; Thu, 17 Jul 2014 14:32:22 -0700 (PDT) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.76.202.229 with HTTP; Thu, 17 Jul 2014 14:32:02 -0700 (PDT) In-Reply-To: <46615CB8-799E-46CE-9EA9-D1FB19843E70@gmail.com> References:

<46615CB8-799E-46CE-9EA9-D1FB19843E70@gmail.com> From: DaeYoung KIM Date: Thu, 17 Jul 2014 23:32:02 +0200 X-Google-Sender-Auth: bR6dRU5VGvSY8njZg0D3q3_kRlE Message-ID: To: Dino Farinacci Content-Type: multipart/alternative; boundary=001a11c2111648b85a04fe6a6008 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/M1yGQGUXfpQawGb08-DORmd5qKo Cc: lisp Subject: Re: [lisp] Q: draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:32:24 -0000 --001a11c2111648b85a04fe6a6008 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 17, 2014 at 10:39 PM, Dino Farinacci wrote: Say you have a cluster of VMs that work together at the applicaiton-layer. > And you want to move them together to a cloud provider. In this case the > EIDs of the VMs in the cluster are part of the same power-of-2 prefix. If only the EIDs already had been assigned out of the same power-of-2 prefix since the cluster of VMs is part of the usual Internet. What if they had not? > In this case, that is an EID-prefix that moves so the new set of RLOCs are > the one that reside at the cloud provider. > An EID-prefix needs only one RLOC, doesn't it? The whole EIDs in the same site would be mapped to the one single RLOC (in the basic model) for the purpose of inter-site routing... > Another related question might be.... is there any compelling reason why > EIDs within a site should better be assigned in the same power-of-2 prefix? > > If they fate-share RLOC changes, they should be assigned in power-of-2 > blocks. > Why should EIDs fate-share RLOC changes? EID are for e2e connection while RLOCs are for routing... > If the EID would be assigned to a node, it wouldn't matter much. Or is it > to save entry space in the mapping server? > > The only real issue with assigning addresses to nodes versus interfaces > (this is a general comment), is if the routers know directly how to reach > the address. When the address is assigned to an interface, routers are > directly attached to the subnet of node's interface address. When it is > assigned say to a loopback interface, the routers need more information to > know what physical interface the node is reachable on. > Not a problem in link-state routing like ISIS or OSPF... or..? -- DY --001a11c2111648b85a04fe6a6008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 17, 2014 at 10:39 PM, Dino Farinacci <farin= acci@gmail.com> wrote:

Say you have a cluster of VMs that work toge= ther at the applicaiton-layer. And you want to move them together to a clou= d provider. In this case the EIDs of the VMs in the cluster are part of the= same power-of-2 prefix.

If only the EIDs already had been assigned out of the s= ame power-of-2 prefix since the cluster of VMs is part of the usual Interne= t.

What if they had not?

=C2=A0

In this case, that is an EID-prefix that moves so the new set of RLOCs are= the one that reside at the cloud provider.

An EID-prefix needs only one RLOC, doesn't it? The whole EIDs in t= he same site would be mapped to the one single RLOC (in the basic model) fo= r the purpose of inter-site routing...

> Another related question might be.... is there any compelling reason w= hy EIDs within a site should better be assigned in the same power-of-2 pref= ix?

If they fate-share RLOC changes, they should be assigned in power-of-2 bloc= ks.

Why should EIDs fate-share RLOC cha= nges? EID are for e2e connection while RLOCs are for routing...

> If the EID would be assigned to a node, it wouldn't matter much. O= r is it to save entry space in the mapping server?

The only real issue with assigning addresses to nodes versus interfaces (th= is is a general comment), is if the routers know directly how to reach the = address. When the address is assigned to an interface, routers are directly= attached to the subnet of node's interface address. When it is assigne= d say to a loopback interface, the routers need more information to know wh= at physical interface the node is reachable on.

Not a problem in link-state routing like I= SIS or OSPF... or..?

--
DY

--001a11c2111648b85a04fe6a6008-- From nobody Thu Jul 17 14:35:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD361A0302 for ; Thu, 17 Jul 2014 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt3lTav_YbZh for ; Thu, 17 Jul 2014 14:35:54 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BE41A02F7 for ; Thu, 17 Jul 2014 14:35:54 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id eb12so1637975oac.8 for ; Thu, 17 Jul 2014 14:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HUP8AOJGZcDtkMk07D6uekSyRJuBXVFtnh2irKj8EJI=; b=SMoP0d/lkwT4hFiJL2DEyfyvvN1pydb1FeWhMR4S4i0Tqqm9ofhOh7IVPr5zHX9J/C sQkYgjtftXsszCCBqPKahevwZ0bxJ6pEJHoKBHOuEF8bmeh+64E4rOMbuTrZbPWod9PH nkGqFbYwBWIVRo5m+Cxm5zSqhWd+xS/DDHXktB0hxavCBmyZ876MR631ifd03SYPNmdy aXBOh37vRM7Z3FFoHyB+7997lfgcDX9EZw0AxnSL3/EZcRvukpN/lY1/FOyTTQAPQ9eL IElRO79dLu73k5qmWSVjbYcJ9ZUMWQ3izgrPgU2XBL9WxMbWmnckYjFwKVa6XtxMXYJM l+xQ== X-Received: by 10.60.76.41 with SMTP id h9mr52483oew.13.1405632954030; Thu, 17 Jul 2014 14:35:54 -0700 (PDT) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.76.202.229 with HTTP; Thu, 17 Jul 2014 14:35:32 -0700 (PDT) In-Reply-To: References:

From: DaeYoung KIM Date: Thu, 17 Jul 2014 23:35:32 +0200 X-Google-Sender-Auth: y-7Ssu12_QX5J342tksgO4is8fU Message-ID: To: Dino Farinacci Content-Type: multipart/alternative; boundary=047d7b33d64ee8e1ee04fe6a6c2e Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vTmL0jnrjCkWuejzWTaMglsiYK0 Cc: lisp Subject: Re: [lisp] Q: draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:35:56 -0000 --047d7b33d64ee8e1ee04fe6a6c2e Content-Type: text/plain; charset=UTF-8 Sorry to others for bothering. On Thu, Jul 17, 2014 at 11:19 PM, Dino Farinacci wrote: > DY and I are going private. If anyone wants a summary of this discussion > DY will provide one. > > Dino > > On Jul 17, 2014, at 2:14 PM, DaeYoung KIM wrote: > > > On Thu, Jul 17, 2014 at 10:33 PM, Dino Farinacci > wrote: > > > > > On Thu, Jul 17, 2014 at 10:03 PM, Dino Farinacci > wrote: > > > But when an EID is assigned to a node (either static or via DHCP) > > > > > > Is there a case in LISP that EID would be assigned to its interface > rather than to a node? > > > > That is independent of LISP. > > > > Yes, in principle. But if you'd maintain the assertion (if such an > assertion has ever been made) that the network elements within a site > doesn't change, it would automatically assumed that > > > > - nodes in a site maintains the IP address (already) assigned, and > > - the IP addresses would have been assigned to the interfaces. > > > > And a node can have multiple EIDs if one chooses to do that. In fact, a > dual-stack host will have two EIDs, one IPv4 and one IPv6. > > > > This multiple EIDs for a node is not my immediate concern in this > discussion. I'm try to confine myself to the most basic model of LISP, in > order better to understand it. > > > > > Somewhere, it is said that the behavior of network elements within a > site doesn't change, which is thought to be one of the major strong feature > of LISP. If that is the case, then the EID would be assigned to the > interface like with the current Internet. > > > > Right, there are no requirements how EIDs are assigned locally within a > system. Remember, the EID is on a unchanged host. From that host's point of > view, it is just an address. From the LISP site's point of view, that > address is reachable via local routing. > > > > This means... (if an EID is assigned to an interface)... the e2e > transport connection would break if a node move from one subnet to another > within a site. LISP doesn't contribute to solving/improving the intra-site > mobility. Right? > > > > > Assuming you really meant the node, not the interface, which existing > mechanism would allow the mobility? OSPF or ISIS? > > > > What I meant is the "IP address" is moving. Saying it that way means no > matter how it is assigned on the local device, what is moving is the IP > address. > > > > I'm still in the same hole. Does this IP address change when a node > moves from one subnet to another or not? > > > > > If you meant, in fact, the interface but not the node in your > discussion of the EID assignment, do you mean a MIP like mechanism would > provide the mobility within a site? > > > > I didn't and don't need to make that distinction. > > > > So, you don't care about the intra-site problems at all. You focus on > the inter-site routing, don't you? > > > > The whole idea of LIS(locator/id separation) is to solve, among many > things, the mobility problem. To ensure that, an ID would be kept constant > at moving of a node while locator would be updated at every such moving. Am > I correct? > > > > However, if behavior of the all network elements within a site doesn't > have to change, as asserted somewhere in the main documents, (this would > mean that ARP is also at work as usual), the ID (in fact, the IP address) > would change at any such moving, which would not keep the EID constant. > Such move would not only break a intra-site connection but also a > connection between sites. > > > > So, you cannot just ignore the intra-site problems. If the EID(IP > address) has to change at every node moving across subnets within a site, > the whole purpose of ID (in LIS) would be questioned. Isn't this in > contradiction to the whole idea of LIS? > > > > If the EID would be kept constant even at moving within a site, then > some network elements within a site have to change their behavior, don't > they? Even the host behavior might have to change like, for example, > shutting off the ARP operation. > > > > Also, EIDs can be flat, as with other usual LIS proposals, and need not > necessarily be out of a power-of-2 EID prefix. Correct? > > > > > So in the static case, that would mean a host route would need to be > injected into the IGP if the node's address stays the same > > > > > > I cannot catch what you exactly mean here by 'injection'. Sorry... > > > > When a host 10.1.1.1 moves off subnet 10.1.0.0/16 to subnet 11.1.0.0/16, > the routers attached to 11.1 need to advertise a 10.1.1.1/32 route into > the routing system. > > > > Got it. This is exactly what ISIS is doing, right? > > > > > So, in short, what mobility solution is provided by LISP in addition > to the existing mobility mechanisms? > > > > There are different scopes of mobility. When you roam across LISP site, > you use LISP mobility. > > > > You mean the tunneling..? Tunneling implicitly provides some sort of > mobility... like that? > > > > When you roam within LISP sites you use IP-mobility or host routes. > > > > So, no additional contribution by LISP as far as intra-site mobility is > concerned. Right? > > > > -- > > DY > > -- DY --047d7b33d64ee8e1ee04fe6a6c2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry to others for bothering.

On Thu, Jul 17, 2014 at 11:19 P= M, Dino Farinacci <farinacci@gmail.com> wrote:

DY and I are going private. If anyone wants = a summary of this discussion DY will provide one.

Dino

On Jul 17, 2014, at 2:14 PM, DaeYoung KIM <dykim@cnu.kr> wrote:

> On Thu, Jul 17, 2014 at 10:33 PM, Dino Farinacci <farinacci@gmail.com> wrote:
>
> > On Thu, Jul 17, 2014 at 10:03 PM, Dino Farinacci <farinacci@gmail.com> wrote:
> > But when an EID is assigned to a node (either static or via DHCP)=
> >
> > Is there a case in LISP that EID would be assigned to its interfa= ce rather than to a node?
>
> That is independent of LISP.
>
> Yes, in principle. But if you'd maintain the assertion (if such an= assertion has ever been made) that the network elements within a site does= n't change, it would automatically assumed that
>
> =C2=A0 - nodes in a site maintains the IP address (already) assigned, = and
> =C2=A0 - the IP addresses would have been assigned to the interfaces.<= br> >
> And a node can have multiple EIDs if one chooses to do that. In fact, = a dual-stack host will have two EIDs, one IPv4 and one IPv6.
>
> This multiple EIDs for a node is not my immediate concern in this disc= ussion. I'm try to confine myself to the most basic model of LISP, in o= rder better to understand it.
>
> > Somewhere, it is said that the behavior of network elements withi= n a site doesn't change, which is thought to be one of the major strong= feature of LISP. If that is the case, then the EID would be assigned to th= e interface like with the current Internet.
>
> Right, there are no requirements how EIDs are assigned locally within = a system. Remember, the EID is on a unchanged host. From that host's po= int of view, it is just an address. From the LISP site's point of view,= that address is reachable via local routing.
>
> This means... (if an EID is assigned to an interface)... the e2e trans= port connection would break if a node move from one subnet to another withi= n a site. LISP doesn't contribute to solving/improving the intra-site m= obility. Right?
>
> > Assuming you really meant the node, not the interface, which exis= ting mechanism would allow the mobility? OSPF or ISIS?
>
> What I meant is the "IP address" is moving. Saying it that w= ay means no matter how it is assigned on the local device, what is moving i= s the IP address.
>
> I'm still in the same hole. Does this IP address change when a nod= e moves from one subnet to another or not?
>
> > If you meant, in fact, the interface but not the node in your dis= cussion of the EID assignment, do you mean a MIP like mechanism would provi= de the mobility within a site?
>
> I didn't and don't need to make that distinction.
>
> So, you don't care about the intra-site problems at all. You focus= on the inter-site routing, don't you?
>
> The whole idea of LIS(locator/id separation) is to solve, among many t= hings, the mobility problem. To ensure that, an ID would be kept constant a= t moving of a node while locator would be updated at every such moving. Am = I correct?
>
> However, if behavior of the all network elements within a site doesn&#= 39;t have to change, as asserted somewhere in the main documents, (this wou= ld mean that ARP is also at work as usual), the ID (in fact, the IP address= ) would change at any such moving, which would not keep the EID constant. S= uch move would not only break a intra-site connection but also a connection= between sites.
>
> So, you cannot just ignore the intra-site problems. If the EID(IP addr= ess) has to change at every node moving across subnets within a site, the w= hole purpose of ID (in LIS) would be questioned. Isn't this in contradi= ction to the whole idea of LIS?
>
> If the EID would be kept constant even at moving within a site, then s= ome network elements within a site have to change their behavior, don't= they? Even the host behavior might have to change like, for example, shutt= ing off the ARP operation.
>
> Also, EIDs can be flat, as with other usual LIS proposals, and need no= t necessarily be out of a power-of-2 EID prefix. Correct?
>
> > So in the static case, that would mean a host route would need to= be injected into the IGP if the node's address stays the same
> >
> > I cannot catch what you exactly mean here by 'injection'.= Sorry...
>
> When a host 10.1.1.1 moves off subnet 10.1.0.0/16 to subnet 11.1.0.0/16, the routers attached to 11.1 need to adve= rtise a 10.1.1.1/32 ro= ute into the routing system.
>
> Got it. This is exactly what ISIS is doing, right?
>
> > So, in short, what mobility solution is provided by LISP in addit= ion to the existing mobility mechanisms?
>
> There are different scopes of mobility. When you roam across LISP site= , you use LISP mobility.
>
> You mean the tunneling..? Tunneling implicitly provides some sort of m= obility... like that?
>
> When you roam within LISP sites you use IP-mobility or host routes. >
> So, no additional contribution by LISP as far as intra-site mobility i= s concerned. Right?
>
> --
> DY

--
DY

--047d7b33d64ee8e1ee04fe6a6c2e-- From nobody Thu Jul 17 14:44:02 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7FF1A0330 for ; Thu, 17 Jul 2014 14:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CvjOF8cZnDC for ; Thu, 17 Jul 2014 14:43:56 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65491A032E for ; Thu, 17 Jul 2014 14:43:55 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id o8so2679469qcw.8 for ; Thu, 17 Jul 2014 14:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZM6sFN0u7ZABTV4D4OR1WAYkHN7cYXkygrjewWhobho=; b=WV7lI3OF/TF5ckCyac6GXr3QbUMyUtc7o+SnXuPJ6xCihZIwp7I2YUKGW/YuFw8KNy Q0IvqFKgjmtQRjNJipIzyIMiraFrwFPyrIgqqUhh1/B/21G9xFNNG0HuxTgJiHgTTDJ7 ztTsAiDyYSiVKYio9uMzjNn8BvOVFurJumbe8k5o5sQHxAR8frhiUUTjaP+vfa+ZyGRT hhHWQmI8mA0SKfv64uwnuqf/Ns7P5HO9QTF18zAoEdPB9P+KmCiOlRxUTe+M71pR2x1X YvRgCT0g/v5cb7xshR2jr2KKWkYNINeL6qhpdyVP3X3bMlcl/BHJX8tPwwTkZpWVH4lW 3qMQ== MIME-Version: 1.0 X-Received: by 10.140.92.235 with SMTP id b98mr40578243qge.97.1405633434921; Thu, 17 Jul 2014 14:43:54 -0700 (PDT) Received: by 10.96.6.42 with HTTP; Thu, 17 Jul 2014 14:43:54 -0700 (PDT) In-Reply-To: References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> <53EE128C-1552-4F00-AECF-6EE8511A4D18@gigix.net>

Date: Thu, 17 Jul 2014 23:43:54 +0200 Message-ID: From: Albert Cabellos To: Dino Farinacci Content-Type: multipart/alternative; boundary=001a113a51b492b3f004fe6a89b3 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/KjIF_nSVgZYe0Dqy7Oj1qM2dWNw Cc: "lisp@ietf.org" Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:43:59 -0000 --001a113a51b492b3f004fe6a89b3 Content-Type: text/plain; charset=UTF-8 Hi Dino I assume you mean this: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-lisp-introduction-04.txt If not please let me know Albert On Thu, Jul 17, 2014 at 10:06 PM, Dino Farinacci wrote: > Could someone supply a diff of the changes between the two -04 versions? > > Dino > > On Jul 17, 2014, at 12:57 PM, Albert Cabellos > wrote: > > > Hi > > > > As Luigi said, we included some minor changes as well as suggestions for > more structural changes. The idea is to discuss them during the WG meeting. > > > > This is the first edit after the interim meeting. > > > > Albert > > > > > > On Thu, Jul 17, 2014 at 5:15 PM, Dino Farinacci > wrote: > > > Like Joel, I would like to invite people read the document despite the > late submission. > > > > One clarification, is this the first edit after the interim meeting we > had in Virgina last year? > > > > Dino > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > > > --001a113a51b492b3f004fe6a89b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Dino

I assume you mean this:

http://tools.ietf.org/rfc= diff?difftype=3D--hwdiff&url2=3Ddraft-ietf-lisp-introduction-04.txt=

If not please let me know

Albert

See you = later

Luigi

On 16 Jul = 2014, at 05:49, Luigi Iannone <ggx@gigix.net> wrote:

Hi = All,

hereafter the final agenda for the LISP WG = session.

To all presenter please send your = slides to the chairs by 13:00 Wednesday 23th July so that we have = time to upload them.

See you next week in = Toronto.

ciao

Luigi

CHAIR(s): Joel Halpern ( jmh = AT joelhalpern.com )
  = ;        Terry Manderson ( = Terry.Manderson AT icann.org )
=    Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Wassim = Haddad ( wassim.haddad AT ericsson.com )
   = ;       Damien Saucez ( damien.saucez = AT gmail.com )

AGENDA

S= ession 1/1 (60 min)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

THURSDA= Y, July 24, 2014
1730-1830, 60 Mins

Administration =        5 = minutes
   Halpern/Manderson/Iannone
&nbs= p; - Blue Sheets
   - Co-Chairs = Composition
   - Agenda Bashing
   - = Status reports for WG drafts

o WG Documents update

- = LISP Introduction
10 minutes
Chairs/D. Saucez/A. = Cabellos

- LISP Threats Analysis
http://tool= s.ietf.org/wg/lisp/draft-ietf-lisp-threats
15 = minutes
= D. Saucez

- LISP EID Block Management
http:/= /tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt
5 = min
= L. Iannone

o Non WG Documents

- LISP OAM = (Operation Administration Management)
http:= //tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00
10 = mins
= A. Cabellos

- LISP Data-Plane = Confidentiality
http://too= ls.ietf.org/html/draft-farinacci-lisp-crypto
10 = mins
= D. Farinacci

- LISP Generic Protocol = Extension
http://tools.ietf= .org/html/draft-lewis-lisp-gpe
5 mins
D. = Lewis

= --Apple-Mail=_4A6B6127-CFF3-4DDE-B477-86CC2F8A6A83-- From nobody Fri Jul 25 05:53:55 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399451B2857 for ; Fri, 25 Jul 2014 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXErl-EINClu for ; Fri, 25 Jul 2014 05:53:47 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6859A1A0242 for ; Fri, 25 Jul 2014 05:53:47 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so3562352ieb.4 for ; Fri, 25 Jul 2014 05:53:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=HgfqxXSOlGweQgRW0MRm6plkLpPSUr0ZCbai5ZnPZ3M=; b=IgiwhmCMGM5Kfn8fNs3k1RrL4RxBs576mL9OqQiCxKE53bVJpif5MhG8C6QxJMHCYU Uau+B8mrI9IMwuUmkJSdK7kTn67xdNSMn7n451WIgbiPmU+/E5ucm2IcuOXj/cxrjCVX aQw6Tn6tuxmm+KjWTNb5xBLHudSiMGcVrbwmM+v0o5W0qjPMQDLFkOsAplUmwrh7kULz qS6Sv/c3q1jX8/FosugrZ+1zOLvDfMrV5BMRszOsvJmJRPIPaJyvo5rU+HMTR5WPemfw mCLRr1d+kFY0OO/YFgpvFcG5FGj6ez2nDpWu7gHlApWjvkzJrw07VHR8p8LniI1QkZTv 4suA== X-Gm-Message-State: ALoCoQlRxMtQkRB7MzpTs8k4YyAFsGtBcB1VBc6j8nxSFrsjhBGZKFZaRNQ31rCfAup5fVpJRpwn X-Received: by 10.50.137.73 with SMTP id qg9mr5204546igb.19.1406292826688; Fri, 25 Jul 2014 05:53:46 -0700 (PDT) Received: from [10.0.1.114] ([199.119.129.50]) by mx.google.com with ESMTPSA id dx6sm4249279igb.15.2014.07.25.05.53.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 05:53:46 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_50195D40-FFB5-409C-B045-E241E2CB95F6" Message-Id: <0570EF83-145C-4001-BE19-9F8138856C66@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 25 Jul 2014 08:53:40 -0400 References:

To: LISP mailing list list In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/z-K23WzWxZqC1gEJqwtgVheAUUQ Subject: Re: [lisp] LISP Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:53:50 -0000 --Apple-Mail=_50195D40-FFB5-409C-B045-E241E2CB95F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Unfortunately, yesterday we run late in our session and we had to shrink = Dino=92s presentation and cut out Darrel=92s presentation. (on the other side we made good progress on other items :-) ) For those interested, their slides are still on the materials page: = https://datatracker.ietf.org/meeting/90/materials.html#int and presenters can send a summary on the mailing list if they want to = discuss about their documents. ciao Luigi =20 On 24 Jul 2014, at 09:21, Luigi Iannone wrote: > Hi All, >=20 > Today=92s slides are now available in the materials page: = https://datatracker.ietf.org/meeting/90/materials.html#int >=20 > See you later >=20 > Luigi >=20 > On 16 Jul 2014, at 05:49, Luigi Iannone wrote: >=20 >> Hi All, >>=20 >> hereafter the final agenda for the LISP WG session. >>=20 >> To all presenter please send your slides to the chairs by 13:00 = Wednesday 23th July so that we have time to upload them. >> =20 >> See you next week in Toronto. >>=20 >> ciao >>=20 >> Luigi >>=20 >>=20 >> CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) >> Terry Manderson ( Terry.Manderson AT icann.org ) >> Luigi Iannone ( ggx AT gigix.net ) >>=20 >> SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) >> Damien Saucez ( damien.saucez AT gmail.com ) >>=20 >>=20 >> AGENDA >>=20 >> Session 1/1 (60 min) >> =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >>=20 >> THURSDAY, July 24, 2014 >> 1730-1830, 60 Mins >>=20 >> Administration 5 minutes=20 >> Halpern/Manderson/Iannone >> - Blue Sheets >> - Co-Chairs Composition >> - Agenda Bashing >> - Status reports for WG drafts >>=20 >>=20 >> o WG Documents update >>=20 >> - LISP Introduction >> 10 minutes >> Chairs/D. Saucez/A. Cabellos >>=20 >> - LISP Threats Analysis >> http://tools.ietf.org/wg/lisp/draft-ietf-lisp-threats >> 15 minutes >> D. Saucez >>=20 >> - LISP EID Block Management=20 >> http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt >> 5 min >> L. Iannone >>=20 >>=20 >>=20 >> o Non WG Documents >>=20 >> - LISP OAM (Operation Administration Management) >> http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00 >> 10 mins >> A. Cabellos >>=20 >> - LISP Data-Plane Confidentiality=20 >> http://tools.ietf.org/html/draft-farinacci-lisp-crypto >> 10 mins >> D. Farinacci >>=20 >> - LISP Generic Protocol Extension=20 >> http://tools.ietf.org/html/draft-lewis-lisp-gpe >> 5 mins >> D. Lewis >=20 --Apple-Mail=_50195D40-FFB5-409C-B045-E241E2CB95F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

Unfortunately, yesterday we = run late in our session and we had to shrink Dino=92s presentation and = cut out Darrel=92s presentation.

(on the other side we made = good progress on other items :-) )

For those = interested, their slides are still on the materials page: https:= //datatracker.ietf.org/meeting/90/materials.html#int

and = presenters can send a summary on the mailing list if they want to = discuss about their = documents.

ciao

Luigi

On 24 Jul 2014, at = 09:21, Luigi Iannone <ggx@gigix.net> wrote:

Hi = All,

Today=92s slides are now available in the = materials page: https:= //datatracker.ietf.org/meeting/90/materials.html#int

See you = later

Luigi

On 16 Jul = 2014, at 05:49, Luigi Iannone <ggx@gigix.net> wrote:

Hi = All,

hereafter the final agenda for the LISP WG = session.

To all presenter please send your = slides to the chairs by 13:00 Wednesday 23th July so that we have = time to upload them.

See you next week in = Toronto.

ciao

Luigi

CHAIR(s): Joel Halpern ( jmh = AT joelhalpern.com )
  = ;        Terry Manderson ( = Terry.Manderson AT icann.org )
=    Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Wassim = Haddad ( wassim.haddad AT ericsson.com )
   = ;       Damien Saucez ( damien.saucez = AT gmail.com )

AGENDA

S= ession 1/1 (60 min)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

THURSDA= Y, July 24, 2014
1730-1830, 60 Mins

Administration =        5 = minutes
   Halpern/Manderson/Iannone
&nbs= p; - Blue Sheets
   - Co-Chairs = Composition
   - Agenda Bashing
   - = Status reports for WG drafts

o WG Documents update

- = LISP Introduction
10 minutes
Chairs/D. Saucez/A. = Cabellos

- LISP Threats Analysis
http://tool= s.ietf.org/wg/lisp/draft-ietf-lisp-threats
15 = minutes
= D. Saucez

- LISP EID Block Management
http:/= /tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt
5 = min
= L. Iannone

o Non WG Documents

- LISP OAM = (Operation Administration Management)
http:= //tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00
10 = mins
= A. Cabellos

- LISP Data-Plane = Confidentiality
http://too= ls.ietf.org/html/draft-farinacci-lisp-crypto
10 = mins
= D. Farinacci

- LISP Generic Protocol = Extension
http://tools.ietf= .org/html/draft-lewis-lisp-gpe
5 mins
D. = Lewis

= --Apple-Mail=_50195D40-FFB5-409C-B045-E241E2CB95F6-- From nobody Fri Jul 25 06:01:09 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BFD1A02DD for ; Fri, 25 Jul 2014 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67HrlD4y__O3 for ; Fri, 25 Jul 2014 06:01:02 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD131A028A for ; Fri, 25 Jul 2014 06:01:02 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id ABD3C8813F for ; Fri, 25 Jul 2014 06:01:02 -0700 (PDT) Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 720CC136811D for ; Fri, 25 Jul 2014 06:01:02 -0700 (PDT) Message-ID: <53D2550D.4080906@innovationslab.net> Date: Fri, 25 Jul 2014 09:01:01 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "lisp@ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="c4fPEQu51Rj15E17D2vSvTPTTmn9xFqr1" Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vPvBPSNh0Gt908gnYZYnFNFLVxc Subject: [lisp] Terry stepping down as co-chair X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:01:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c4fPEQu51Rj15E17D2vSvTPTTmn9xFqr1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, For those of you who were not able to be in Toronto, Terry is stepping down as co-chair. I want to thank Terry for filling this role so admirably for the past 4.5+ years. Regards, Brian --c4fPEQu51Rj15E17D2vSvTPTTmn9xFqr1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT0lUOAAoJEBOZRqCi7goqZJgH+wdmcPai7KcEJLuBzmYHagd8 PauYxuv24cPHBatbXlPBIJRaTdg/ujVPdmiK5pR8FB2uTlgaPQ1TmFX74+flw/sw BiOkjbniAHKhAi+LQipmYnlmNagjI8m9OW0FU6VdrqIa/pZofip/ufvnGlXrxbdH TBvFGoX+vuugZRSNE2G0I42+F4J3ofcfwi470JqbDfwQVwEujqRcx3UjgJpeBw3s ZJgEIQQK9BveCXanSUWKMALx/eAeSWfQpICWBm3jElTyZmPAwYc7zy+ua+xF5FKi zVsTKikhiZVZnHwmJQJNg36J2EdpI46pa7tVALaAExBbYwEBY5wENJ5M2pFkrk4= =bmNV -----END PGP SIGNATURE----- --c4fPEQu51Rj15E17D2vSvTPTTmn9xFqr1-- From nobody Fri Jul 25 06:16:06 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BAB1B2831 for ; Fri, 25 Jul 2014 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PbS74y_d4vP for ; Fri, 25 Jul 2014 06:15:55 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FCD1A028A for ; Fri, 25 Jul 2014 06:15:55 -0700 (PDT) Received: from PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 25 Jul 2014 06:15:52 -0700 Received: from PMBX112-W1-CA-2.pexch112.icann.org ([64.78.40.23]) by PMBX112-W1-CA-2.PEXCH112.ICANN.ORG ([64.78.40.23]) with mapi id 15.00.0847.030; Fri, 25 Jul 2014 06:15:52 -0700 From: Terry Manderson To: Brian Haberman , "lisp@ietf.org" Thread-Topic: [lisp] Terry stepping down as co-chair Thread-Index: AQHPqAiPy6qznkf8Ika2eEjsJ4xBH5ux4gYA Date: Fri, 25 Jul 2014 13:15:51 +0000 Message-ID: References: <53D2550D.4080906@innovationslab.net> In-Reply-To: <53D2550D.4080906@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [31.133.145.196] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3489174950_50047693" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/4mKiSx-7iZtegBYB9Zg6PSpMKuk Subject: Re: [lisp] Terry stepping down as co-chair X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:15:57 -0000 --B_3489174950_50047693 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks Brian, Even though I have stepped down, I will still be engaged in the workgroup and looking forward to participating without the mantle of co-chair. I am more than comfortable that Luigi will take all that the role can throw at him, in his stride. Cheers Terry On 25/07/2014 11:01 pm, "Brian Haberman" wrote: >All, > For those of you who were not able to be in Toronto, Terry is >stepping down as co-chair. I want to thank Terry for filling this role >so admirably for the past 4.5+ years. > >Regards, >Brian > --B_3489174950_50047693 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFDQEb8mkyXDOXtjHvQ7EomDkytCMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE0MDcyNTEzMTU1MFowDQYJKoZIhvcNAQEBBQAEggEAYpfotbJf IyX+p+EVDZ9Bo3GfFr3k+HeLQsDhuiUtBqDSvF8VSE140/ch8Cj6dw25ETD9jarzhSTvVkZk LhZI9hZcoBsqYWULNuBqPkA6f5Ea6/exMj0os5Y3LToGfwhFTXi3vA6oTTK1LsAFLAgAbXtF FZYr2lRtfJL3RyR+7Ibwmyp4c2zbJg0uT/tJQ9zVJjkNZv9loRX7XKGGiRyBPSLhYY+B1SYl WbX3hrXtnt1CFlAOaY9byW7MXQWH3e6tR+fg8TgLXjL1wgLhs4Qu/RQy/Gd77pwFyzotgUPK /zIbJ988+slHPHx3p5Wrk0atASAfRpvF/c8T12Vtb9ZUlA== --B_3489174950_50047693-- From nobody Fri Jul 25 07:30:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3D51B2957 for ; Fri, 25 Jul 2014 07:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4zPp1pK_cc1 for ; Fri, 25 Jul 2014 07:30:56 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A821A029F for ; Fri, 25 Jul 2014 07:30:46 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so4288399wes.18 for ; Fri, 25 Jul 2014 07:30:42 -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=voGUrL92FlDl9KsrSBWyPflGP/R80Y6z51qzYRIHjDw=; b=HOKnNWrbpTwnXZNM0X4Rdm4XLFJnTzw3b6sIgLt+Z8zU+JFTPCTPhbrvmaKQ7xR6uK 5rUHm/ij7vnwZO6DMnCp3ljdedF7WsQtj86Xhk1wspD54qbitulhZVC513eaoVpVPBsb tcKj78QoFQQig6IgU5lSivTbN+askJv7GrApxqbKef4kp59XLaS5U5veSHGQDfVgerua ujF6UlTUo7JzlpenSWh13C4b/895OKEB6Y9o4Fpg0vdgdS/M0Qq+3OCPyFWbp1UQaJ/x gSHUtOLZyDoeCsoGXfDe8RlyqimJWedfoZSEV8Gfvfs3aWl2oggzZnBpx3hDmFFTOkWY 37qw== X-Received: by 10.194.62.140 with SMTP id y12mr22536077wjr.27.1406298641994; Fri, 25 Jul 2014 07:30:41 -0700 (PDT) Received: from dhcp-9525.meeting.ietf.org (dhcp-9525.meeting.ietf.org. [31.133.149.37]) by mx.google.com with ESMTPSA id de5sm6570108wib.18.2014.07.25.07.30.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 07:30:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Fri, 25 Jul 2014 07:30:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8ECCB088-F615-4983-8D75-058A8DD94A4A@gmail.com> References: <53D2550D.4080906@innovationslab.net> To: Terry Manderson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/CKCGv9btuAyCtkYCNFlzMOLs5Fk Cc: "lisp@ietf.org" Subject: Re: [lisp] Terry stepping down as co-chair X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:30:58 -0000 I'd like to give a special thank you to Terry.=20 Not only did he manage the admin part of being a working group chair = very well, he was always engaged technically and contributed quite a bit = to the raw technology. His practical operational experience and hands-on = involvement in the LISP beta network proved extremely valuable in making = LISP more than just an academic architecture. Thanks again Terry and we all look forward continuing to work with you! Dino On Jul 25, 2014, at 6:15 AM, Terry Manderson = wrote: > Thanks Brian, >=20 > Even though I have stepped down, I will still be engaged in the = workgroup > and looking forward to participating without the mantle of co-chair. >=20 > I am more than comfortable that Luigi will take all that the role can > throw at him, in his stride. >=20 > Cheers > Terry >=20 > On 25/07/2014 11:01 pm, "Brian Haberman" = wrote: >=20 >> All, >> For those of you who were not able to be in Toronto, Terry is >> stepping down as co-chair. I want to thank Terry for filling this = role >> so admirably for the past 4.5+ years. >>=20 >> Regards, >> Brian >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Jul 25 12:14:41 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5CB1A03D4 for ; Fri, 25 Jul 2014 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZocecKJA07zY for ; Fri, 25 Jul 2014 12:14:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D621A03CF for ; Fri, 25 Jul 2014 12:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=659; q=dns/txt; s=iport; t=1406315678; x=1407525278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ItymiCGSHZSl6C4dMqGgmtqw5dLf6zKKqEmCFIAkyN8=; b=IlITJ1LRUcgbB0Cbw/J96qn17EhxdcGftWoJ3Y7863kVtTMr08a9dspg KgkN/t1+hurZvwk2ycadwB5j6LV9eNJAwnOYnSnTj1SPJTsXxtu9TUvVM jpoSffye836yM2zzFzaaX8Tq1OCn/BqlghiSnOpXRsevzPAeveyINdTmk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAEis0lOtJA2J/2dsb2JhbABZgw5SVwTLagqHRQGBEBZ3hAQBAQMBAQEBawsFCwIBCEYnCyUCBA4FiDoIDb9BEwSPGDMHgy6BGwEEijeREJRKg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="64090637" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 25 Jul 2014 19:14:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6PJEbEk004339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 19:14:37 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 14:14:36 -0500 From: "Darrel Lewis (darlewis)" To: Brian Haberman Thread-Topic: [lisp] Terry stepping down as co-chair Thread-Index: AQHPqDyswAS9qLuJlUyP44Ju4te/Sw== Date: Fri, 25 Jul 2014 19:14:36 +0000 Message-ID: References: <53D2550D.4080906@innovationslab.net> In-Reply-To: <53D2550D.4080906@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.109] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5BB12A5E4EAD6A4A8C1DD0434D91C00A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/6vtKluV2JZjSZjx30PZ15vW75L0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Terry stepping down as co-chair X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:14:39 -0000 Terry will be missed. Contribution were many. Change is refreshing. -Darrel p.s. With apologies to our work, and its seriousness, my respect for Terry = demands that I submit to his request for Haiku. On Jul 25, 2014, at 6:01 AM, Brian Haberman wrot= e: > All, > For those of you who were not able to be in Toronto, Terry is > stepping down as co-chair. I want to thank Terry for filling this role > so admirably for the past 4.5+ years. >=20 > Regards, > Brian >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Jul 25 13:21:44 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8451A0342 for ; Fri, 25 Jul 2014 13:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.802 X-Spam-Level: X-Spam-Status: No, score=-11.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0kSbOEHfvxy for ; Fri, 25 Jul 2014 13:21:22 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F791A008B for ; Fri, 25 Jul 2014 13:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=154931; q=dns/txt; s=iport; t=1406319682; x=1407529282; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=G2YtsxvWC1l6nlUSXda8fDJ7DmNWkANGOb8I70uHmNw=; b=CXoKLgIP/VpmMeRmHbdDkP93GSj+fnb3WEEw/7F/iApWlFzA4Z97rF0U j1ZQBQtio3gwm2Yf4alcwkc2AYPEceRTZUmzdT/3DjONSf+A1WiQl67bH NfTDmI8gWVaEot1cI7Kh0cEXFQ3lALr1eCpyDCSBuyAWZdlItkUrL2jDH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcKAEu70lOtJA2H/2dsb2JhbABPAQYDDgiCeFJXxXyFV4dFAYEQFneEBAEBAwEODAEMES0CAQQBAQYCAgYLCxIPFg8JAwIBAgE3DgYBDAYCAQEFCweIHwgNv08XiX6EYAoBBgEDAQUCAQEMMgsMEYQ4AQSWXkqEH4FShUyNLIMGXiEvAYECAQEeBAI X-IronPort-AV: E=Sophos;i="5.01,733,1400025600"; d="scan'208";a="64101257" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 25 Jul 2014 20:21:15 +0000 Received: from [10.21.148.213] (sjc-vpn7-1237.cisco.com [10.21.148.213]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6PKLEN9011090; Fri, 25 Jul 2014 20:21:15 GMT Message-ID: <53D2BC3B.1090308@cisco.com> Date: Fri, 25 Jul 2014 16:21:15 -0400 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lisp@ietf.org, Albert Cabellos , Damien Saucez References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> <53EE128C-1552-4F00-AECF-6EE8511A4D18@gigix.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/TSFJ9135Uu0QU-qSO5p8I1k-CFs Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 20:21:42 -0000 Albert, Damien, please find my comments below. > Network Working Group A. Cabellos-Aparicio (Ed.) > Internet-Draft Technical University of Catalonia > Intended status: Informational D. Saucez (Ed.) > Expires: January 17, 2015 INRIA > July 16, 2014 > > > An Architectural Introduction to the LISP Location-Identity > Separation System > draft-ietf-lisp-introduction-04.txt > > Abstract > > This document is an introductory overview of the Locator/ID > Separation Protocol, it describes the major concepts and functional > sub-systems of LISP and the interactions between them. > > 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 athttp://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 17, 2015. > > Copyright Notice > > Copyright (c) 2014 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. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 1] > > Internet-Draft LISP Introduction July 2014 > > > Table of Contents > > 1. Prefatory Note . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Initial Glossary . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 5. Deployment Philosophy . . . . . . . . . . . . . . . . . . . . 7 > 5.1. Economics . . . . . . . . . . . . . . . . . . . . . . . . 7 > 5.2. Maximize Re-use of Existing Mechanism . . . . . . . . . . 8 > 6. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 > 6.1. Basic Approach . . . . . . . . . . . . . . . . . . . . . 9 > 6.2. Basic Functionality . . . . . . . . . . . . . . . . . . . 9 > 6.3. Mapping from EIDs to RLOCs . . . . . . . . . . . . . . . 11 > 6.4. Interworking With Non-LISP-Capable Endpoints . . . . . . 11 > 6.5. Security in LISP . . . . . . . . . . . . . . . . . . . . 12 > 7. Initial Applications . . . . . . . . . . . . . . . . . . . . 13 > 7.1. Provider Independence . . . . . . . . . . . . . . . . . . 13 > 7.2. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . 13 > 7.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 14 > 7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 7.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 15 > 7.6. Traversal Across Alternate IP Versions . . . . . . . . . 15 > 7.7. Virtual Private Networks . . . . . . . . . . . . . . . . 16 > 7.8. Local Uses . . . . . . . . . . . . . . . . . . . . . . . 16 > 8. Major Functional Subsystems . . . . . . . . . . . . . . . . . 17 > 8.1. Data Plane - xTRs Overview . . . . . . . . . . . . . . . 17 > 8.1.1. Mapping Cache Performance . . . . . . . . . . . . . . 18 > 8.2. Control Plane - Mapping System Overview . . . . . . . . . 18 > 8.2.1. Mapping System Organization . . . . . . . . . . . . . 19 > 8.2.2. Interface to the Mapping System . . . . . . . . . . . 20 > 8.2.3. Indexing Sub-system . . . . . . . . . . . . . . . . . 20 > 9. Examples of operation . . . . . . . . . . . . . . . . . . . . 22 > 9.1. An Ordinary Packet's Processing . . . . . . . . . . . . . 22 > 9.2. A Mapping Cache Miss . . . . . . . . . . . . . . . . . . 23 > 10. Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 > 11. Design Approach . . . . . . . . . . . . . . . . . . . . . . . 24 > 12. xTRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 > 12.1. When to Encapsulate . . . . . . . . . . . . . . . . . . 25 > 12.2. UDP Encapsulation Details . . . . . . . . . . . . . . . 26 > 12.3. Header Control Channel . . . . . . . . . . . . . . . . . 26 > 12.3.1. Mapping Versioning . . . . . . . . . . . . . . . . . 26 > 12.3.2. Echo Nonces . . . . . . . . . . . . . . . . . . . . 27 > 12.3.3. Instances . . . . . . . . . . . . . . . . . . . . . 27 > 12.4. Probing . . . . . . . . . . . . . . . . . . . . . . . . 28 > 12.5. Mapping Lifetimes and Timeouts . . . . . . . . . . . . . 28 > 12.6. Mapping Gleaning in ETRs . . . . . . . . . . . . . . . . 29 > 12.7. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 29 > 12.8. Security of Mapping Lookups . . . . . . . . . . . . . . 29 > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 2] > > Internet-Draft LISP Introduction July 2014 > > > 12.9. ITR Mapping Cache Performance . . . . . . . . . . . . . 30 > 13. The Mapping System . . . . . . . . . . . . . . . . . . . . . 31 > 13.1. The Mapping System Interface . . . . . . . . . . . . . . 32 > 13.1.1. Map-Request Messages . . . . . . . . . . . . . . . . 32 > 13.1.2. Map-Reply Messages . . . . . . . . . . . . . . . . . 32 > 13.1.3. Map-Register and Map-Notify Messages . . . . . . . . 33 > 13.2. The DDT Indexing Sub-system . . . . . . . . . . . . . . 34 > 13.3. Reliability via Replication . . . . . . . . . . . . . . 35 > 13.4. Security of the DDT Indexing Sub-system . . . . . . . . 35 > 13.5. Extended Capabilities . . . . . . . . . . . . . . . . . 36 > 13.6. Performance of the Mapping System . . . . . . . . . . . 36 > 14. Multicast Support in LISP . . . . . . . . . . . . . . . . . . 37 > 14.1. Basic Concepts of Multicast Support in LISP . . . . . . 37 > 14.2. Initial Multicast Support in LISP . . . . . . . . . . . 38 > 15. Deployment Issues and Mechanisms . . . . . . . . . . . . . . 39 > 15.1. LISP Deployment Needs . . . . . . . . . . . . . . . . . 39 > 15.2. Interworking Mechanisms . . . . . . . . . . . . . . . . 40 > 15.2.1. Proxy LISP Routers . . . . . . . . . . . . . . . . . 40 > 15.2.2. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . 42 > 15.3. Use Through NAT Devices . . . . . . . . . . . . . . . . 42 > 15.4. LISP and Core Internet Routing . . . . . . . . . . . . . 43 > 16. Fault Discovery/Handling . . . . . . . . . . . . . . . . . . 43 > 16.1. Handling Missing Mappings . . . . . . . . . . . . . . . 44 > 16.2. Outdated Mappings . . . . . . . . . . . . . . . . . . . 44 > 16.2.1. Outdated Mappings - Updated Mapping . . . . . . . . 44 > 16.2.2. Outdated Mappings - Wrong ETR . . . . . . . . . . . 44 > 16.2.3. Outdated Mappings - No Longer an ETR . . . . . . . . 45 > 16.3. Erroneous Mappings . . . . . . . . . . . . . . . . . . . 45 > 16.4. Verifying ETR Liveness . . . . . . . . . . . . . . . . . 45 > 16.5. Verifying ETR Reachability . . . . . . . . . . . . . . . 46 > 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 > 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 > 19. Security Considerations . . . . . . . . . . . . . . . . . . . 47 > 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 > 20.1. Normative References . . . . . . . . . . . . . . . . . . 47 > 20.2. Informative References . . . . . . . . . . . . . . . . . 49 > Appendix A. Glossary/Definition of Terms . . . . . . . . . . . . 52 > Appendix B. Other Appendices . . . . . . . . . . . . . . . . . . 55 > B.1. A Brief History of Location/Identity Separation . . . . 55 > B.2. A Brief History of the LISP Project . . . . . . . . . . . 56 > B.3. Old LISP 'Models' . . . . . . . . . . . . . . . . . . . . 56 > B.4. The ALT Mapping Indexing Sub-system . . . . . . . . . . . 57 > B.5. Early NAT Support . . . . . . . . . . . . . . . . . . . . 58 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 3] > > Internet-Draft LISP Introduction July 2014 > > > 1. Prefatory Note > > {{Suggestion by editors: Remove all the sections before "LISP > Overview" and write a straight-to-the-point introduction}} > > {{Suggestion by editors: The draft should focus on describing the > LISP architecture and avoid comparing loc/id split architectures with > other approaches}} Agree: my suggestion is to view this as a doc for a reader new to LISP that needs to be introduced to the architecture. At the end of the doc the reader will be familiar with the basic aspects of LISP, and able to navigate through the RFCs. The document should be kept as short and as "dry" as possible. If the reader wants to know more, after reading this doc, he will know where to go for the details. > This document is the first of a pair which, together, form what one > would think of as the 'architecture document' for LISP (the > 'Location-Identity Separation Protocol'). Much of what would > normally be in an architecture document (e.g. the architectural > design principles used in LISP, and the design considerations behind > various components and aspects of the LISP system) is in the second > document, the 'Architectural Perspective on LISP' document. > [I-D.ietf-lisp-perspective] > > This 'Architectural Introduction' document is primarily intended for > those who are unfamiliar with LISP, and want to start learning about > it. It is intended primarily for those working on LISP, but those > working with LISP, and more generally anyone who wants to know more > about LISP, may also find this document useful. > > This document is intended to both be easy to follow and it is > structured as a series of phases, each covering the entire system, > but with ever-increasing detail. Reading only the first part of the > document will give a good high-level view of the system; reading the > complete document should provide a fairly detailed understanding of > the entire system. > > People who just want to get an idea of how LISP works might only read > the first part; they can stop reading either just before, or just > after Section 9. People who are going to go on and read the protocol > specifications (perhaps to implement LISP) should read the entire > document. > > This document is a descriptive document, not a protocol > specification. Should it differ in any detail from any of the LISP > protocol specification documents, they take precedence for the actual > operation of the protocol. > > 2. Part I > > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 4] > > Internet-Draft LISP Introduction July 2014 > > > 3. Initial Glossary let's stick to the RFCs glossary. Since this is a first-to-read doc there should be a minimal definition section, but definitions should mostly be cut and paste from the RFCs. > This initial glossary defines a few general terms which will be > useful to have in hand when commencing reading this document. A > complete glossary is available in Appendix A. > > A note about style: initial usage of a term defined in the glossary > is denoted with double quotation marks ("). Other uses of quotations > (e.g. for quotations, euphemisms, etc) use single quotation marks > ('). > > o Name: a name refers to an identifier for an object or entity. > Names have both semantics (meaning) and syntax (form) [RFC1498]. > > o Namespace: A group of names with matching semantics and syntax; > they usually, but not always, refer to members of a class of > identical objects. > > o Mapping: a binding between two names, one in each of two > namespaces. > > o Delegation Hierarchy: an abstract rooted tree (in the graph theory > sense of the term) which is a virtual representation of the > delegation of a namespace into smaller and smaller blocks, in a > recursive process. > > o Node: The general term used to describe any sort of communicating > entity; it might be a physical or a virtual host, or a mobile > device of some sort. It includes both entities which forward > packets, and entities which create or consume packets. > > o Switch, Packet Switch: A packet switch, in the general meaning of > that term. A device which takes in packets from its interfaces > and forwards them on, either to a next-hop switch, or to the final > destination. They may operate at either the network layer (e.g. > ARPANET), or internetwork layer. [Baran][Heart][RFC1812] > > o Endpoint, end-end communication entity: The fate-sharing region at > one end of an end-end communication; the collection of state > related to both the reliable end-end communication channel, and > the applications running there. [Chiappa] > > o Address: In this document, in current IP (IPv4 or IPv6) and > similar networking suites, a "name" which has mixed semantics, in > that it includes both identity ('who') and location ('where') > semantics. [Atkinson] > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 5] > > Internet-Draft LISP Introduction July 2014 > > > o Address Block, Block: A contiguous section of a namespace (e.g., > IP addresses that belong to the same prefix). > > o Identifier: a name which has identity semantics. > > o Locator: name with only location semantics and not necessarily > carried in every packet [RFC1992]. > > o Site: A collection of hosts, routers, and networks under a single > administrative control. > > o LISP site: a site separated from the rest of the network by LISP > routers. > > o LISP node: A network element implementing LISP functionality; this > means it can process some subset of LISP control and planes > traffic. > > o LISP router: A network element implementing LISP data-plane > functionality, i.e., a LISP node which can forward user traffic. > > o LISP host: A host which is behind (from the point of view of the > rest of the network) a LISP router. > > 4. Background > > It has gradually been realized in the networking community that > networks, especially large networks, should deal quite separately > with the identity and location of an endpoint - basically, who an > endpoint is, and where it is ([RFC1498] [RFC4984]). > > At the moment of this writing, in both IPv4 and IPv6, IP addresses > indicate both where the named node is, as well as identify it for > purposes of end-end communication; i.e. it has both location and > identity properties. However, the separation of those two properties > is a step which has been identified by the IRTF as a necessary > evolutionary architectural step for the Internet [RFC6115] and the > on-going LISP project is an attempt to provide a viable path towards > this separation. > > As an add-on to a large existing system, it has had to make certain > compromises. (For a good example, see [I-D.ietf-lisp-perspective], > Section "Residual Location Functionality in EIDs". However, if it > reaches near-ubiquitous deployment, it will have two important > consequences. > > First, in effectively providing separation of location and identity, > along with providing a distributed directory of the mappings between > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 6] > > Internet-Draft LISP Introduction July 2014 > > > them, 'Wheeler's Law' ('All problems in computer science can be > solved by another level of indirection') will come into play, and the > Internet technical community will have a new, immensely powerful, > tool at its disposal. The fact that the namespaces on both sides of > the mapping are global ones maximizes the power of that tool. (See > [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for > more on this.) > > Second, because of a combination of the flexible capability built > into LISP, and the breaking of the unification of location and > identity names, further architectural evolution of the Internet > becomes easily available; for example, new namespaces for location or > identity could be designed and deployed. In other words, LISP is not > a point solution to meet a particular need, but hopefully an 'escape > hatch' which will allow further significant enhancement to the > Internet's overall architecture. (See [Future] for more on this.) > > 5. Deployment Philosophy > > {{Suggestion by editors: Remove the entire section, it can be > summarized by the last paragraph. Furthermore the arguments used in > this sections are hard to follow since LISP has not been described > yet.}} > > The deployment philosophy was a major driver for the design of LISP > (architecture and engineering). > > Experience over the last several decades has shown that having a > viable deployment model for a new design is a key to the adoption of > the solution. In general, it is comparatively easy to conceive of > new network designs, but much harder to devise approaches which will > actually get deployed throughout the global network. A new design > may be fantastic but if it can not be successfully deployed (for > whatever factors), it is useless. > > LISP aims to achieve the near-ubiquitous deployment necessary for > maximum exploitation of an architectural upgrade by i) minimizing the > amount of change needed (most existing hosts and routers can operate > unmodified); and ii) by providing significant benefits to early > adopters. > > 5.1. Economics > > {{Suggestion by editors: Remove this section, this has not been > discussed by the WG}} > > A key factor in successful adoption is economics: does the new design > have benefits which outweigh its costs? > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 7] > > Internet-Draft LISP Introduction July 2014 > > > More importantly, this balance needs to hold for early adopters - > because if they do not receive benefits to their adoption, the sphere > of earliest adopters will not expand, and it will never get to > widespread deployment. > > This is particularly true of architectural enhancements, which are > far less likely to be an addition which one can bolt onto the side of > existing mechanisms, and often offer their greatest benefits only > when widely (or ubiquitously) deployed. > > Maximizing the cost-benefit ratio obviously has two aspects. First, > on the cost side, by making the design as inexpensive as possible, > which means in part making the deployment as easy as possible. > Second, on the benefit side, by providing many new capabilities, > which is best done not by loading the design up with lots of features > or options (which adds complexity), but by making the addition > powerful through deeper flexibility. The LISP community believes > LISP has met both of these goals. > > 5.2. Maximize Re-use of Existing Mechanism > > {{Suggestion by editors: Remove/Summarize the entire section, the > arguments used in this section are hard to follow since LISP has not > been described yet.}} Remove. This doc is not a guide to good protocol design. The concept that LISP is deployable incrementally should be mentioned in the document though, possibly with a reference to the deployment RFC. > One key part of reducing the cost of a new design is to minimize the > amount of change required to existing, deployed, devices: the fewer > devices need to be changed, and the smaller the change to those that > do, the greater the likelihood of deployment. > > Designs which absolutely require forklift upgrades to large amounts > of existing gear are far less likely to succeed - because they have > to have extremely large benefits to make their very substantial costs > worthwhile. > > It is for this reason that LISP, in most cases, initially requires no > changes to almost all existing devices in the Internet (both hosts > and routers); LISP functionality needs to be added in only a few > places ( Section 15.1) > > 6. LISP Overview > > LISP is an incrementally deployable architectural upgrade to the > existing Internet infrastructure, one which provides separation of > location and identity. It thus starts to separate the names used for > identity and location of nodes, which are currently unified in IP > addresses. > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 8] > > Internet-Draft LISP Introduction July 2014 > > > 6.1. Basic Approach > > {{Suggestion by editors: Merge this section with the previous one > (LISP Overview)}} Agree: across the document, as done in the RFCs, I'd suggest to focus on describing the protocol architecture and how it works rather than on more generic considerations about the LISP philosophy. > In LISP, the first key concept is that nodes have both an identifier > called an Endpoint IDentifier (EID) and an associated Routing Locator > (RLOC). A node may be associated with more than one RLOC, or the > RLOC may change over time (e.g., if the node is mobile), but it would > normally always have the same EID. > > The second key concept is that if one wants to be as forward-looking > as possible, conceptually one should think of the two kinds of names > (EIDs and RLOCs) as naming different classes of entities. > > On the one hand, EIDs are used to name nodes - or rather, their end- > end communication entities. RLOC(s), on the other hand, name > interfaces, i.e. places to which the system of routers sends packets. > > This distinction, the formal recognition of different kinds of > entities ("endpoints" and interfaces), and their association with the > two different classes of names, is also important. Clearly > recognizing interfaces and endpoints as distinctly separate classes > of objects is another improvement to the existing Internet > architecture. > > An important insight in LISP is that it initially uses existing IP > addresses for both of these kinds of names, as opposed to some > similar earlier deployment proposals for separation of location and > identity (e.g. [RFC1992]), which proposed using a new namespace for > locators. This choice minimizes LISP's deployment cost, as well as > providing the ability to easily interact with un-modified hosts and > routers. > > The capability to use namespaces other than IP addresses for both > kinds of names is already built in LISP, which is expected to greatly > increase the long-term benefits, flexibility, and power of LISP > ([AFI], [I-D.ietf-lisp-lcaf]). > > 6.2. Basic Functionality > > {{Suggestion by editors: Rewrite this section: It is using non- > standard terminology to refer to standard LISP concepts ('enhance' > instead of encapsulate) It is using subjective terms (e.g., 'near' > the source) It is missing key LISP aspects such as that RLOC packets > are forwarded in the RLOC space }} Make sure a figure with the basic elements of the protocol architecture (possibly similar to figure 1) is introduced as early as possible. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 9] > > Internet-Draft LISP Introduction July 2014 > > > The basic operation of LISP, as it currently stands, is quite simple. > LISP augmented packet switches, "LISP routers", near the source and > destination of packets intercept traffic, and 'enhance' the packets > for the trip between the LISP switches. > > The LISP router near the original source (the Ingress Tunnel Router, > or ITR ) looks up additional information about the destination of the > packet, and then wraps the packet in an outer header, one which > contains additional information related to LISP operation. > > The LISP router near the destination, the (the Egress Tunnel Router, > or ETR) removes that header, leaving the original, un-modified, > packet to be sent on to the original destination node. > > The overall processing is shown below, in Figure 1: > > > /-----------------\ --- > | Mapping | | > . System | | Control > -| |`, | Plane > ,' \-----------------/ . | > / \ --- > ,.., - _,..--..,, `, ,.., | > / ` ,' ,-` `', . / ` | > / \ +-----+ ,' `, +--'--+ / \ | > | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data > | Space |-| |---| Space |---| |-| Space | | Plane > \ / +-----+ . / +-----+ \ / | > `. .' `. ,' `. .' | > `'-` `., ,.' `'-` --- > ``''--''`` > LISP Site (Edge) Core LISP Site (Edge) > > Figure.- An schema of the LISP Architecture > > > > Figure 1: Basic LISP Packet Flow > > To retrieve that additional information, the ITR uses the information > in the original packet about the identity of its ultimate > destination, i.e. the destination EID address. It uses the > destination EID to look up the current location (the RLOC) of that > EID. > > The lookup is performed through a mapping system, which is the heart > of LISP: it is a distributed directory of mappings from EIDs to > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 10] > > Internet-Draft LISP Introduction July 2014 > > > RLOCs. The destination RLOC(s) is (are) normally the address(es) of > the ETR(s) near the ultimate destination. > > The ITR then generates a new outer header for the original packet, > with that header containing the ETR's RLOC as the wrapped packet's > destination, and the ITR's own address (i.e. the RLOC usually > associated with the original source) as the wrapped packet's source, > and sends it off. > > When the packet arrives at the ETR, that outer header is stripped > off, and the original packet is forwarded to the original ultimate > destination for normal processing. > > Return traffic is handled similarly, often (depending on the > network's configuration) with the original ITR and ETR switching > roles. The ETR and ITR functionality is usually co-located in a > single LISP router; these are normally denominated as xTRs. > > 6.3. Mapping from EIDs to RLOCs > > The mappings from EIDs to RLOCs are provided by a distributed, and > potentially replicated, database, the "mapping database", which is > the heart of LISP. Here, and in other places in LISP, the > replication is not a deep architectural concept, simply an > engineering device to obtain reliability via potential redundancy. > > Entities which need EID-to-RLOC mappings get them from the mapping > system, which is a collection of sub-systems through which clients > can find and obtain mappings as discussed in more details in > Section 8.2 and Section 13. > > Mappings are normally distributed via a pull mechanism (i.e., not > pre-loaded, but requested on demand). Once obtained by an ITR, they > are cached for performance reasons. > > 6.4. Interworking With Non-LISP-Capable Endpoints > > It is clearly crucial to provide the capability for easy > interoperation between "LISP hosts" - i.e. they are behind xTRs, and > their EIDs are in the mapping database - and existing non-LISP-using > hosts (often called 'legacy' hosts) or legacy "sites". > > To allow interoperation between devices hosted in a LISP site and > devices not belonging to a LISP site (non-LISP site), an interworking > mechanism based on proxies has been designed. Proxy ITRs (PITR) > encapsulate packets sent from non-LISP sites to LISP sites while > Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non- > LISP sites. More details are given in Section 15.2.1. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 11] > > Internet-Draft LISP Introduction July 2014 > > > 6.5. Security in LISP > > {{Suggestion by editors: Rewrite this section: (first 3 paragraphs) > It contains a general discussion as well as strong statements that > are not supported by any WG document. (last 3 paragraphs) It > enumerates the security mechanisms specified in LISP but does not > describe them.}} Agree. I think that the security considerations section of RFC6830 may provide a guide to the items you may want to touch in this document. Point the reader to the RFCs when possible. Move broader security considerations to the Security Section referencing lisp-threats where needed. > To provide a brief overview of security in LISP, it is definitely > understood that LISP needs to be highly _securable_, especially in > the long term; over time, the attacks mounted by 'bad guys' are > becoming more and more sophisticated. So LISP, like DNS, needs to be > _capable_ of providing 'the very best' security there is. > > At the same time, there is a conflicting goal: it must be deployable > at a a viable cost. That means two things: First, as an experiment, > we cannot expect to create the complete security apparatus which we > might see in the finished product, including both design and > implementation. Second, security needs to be flexible, so that we > don't overload the users with more security than they need at any > point. > > To accomplish these divergent goals, the approach taken is to first > analyze what LISP needs for security. [I-D.ietf-lisp-threats]. > Then, steps can be taken to ensure that the appropriate 'hooks' (such > as packet fields) are included at an early stage, when doing so is > still easy. Over time, additional mechanisms will be fully > specified, implemented, and deployed. > > LISP does already include a number of security mechanisms; in > particular, requesting mappings can be secured (see Section 12.8, > "Security of Mapping Lookups"), as can registering of xTRs (see > Section 13.1.3, "Map-Register and Map-Notify Messages"); the key > database of the mapping system is also secured (see Section 13.4, > "Security of the DDT Indexing Sub-system"). > > The existing security mechanisms, and their configuration (which is > mostly manual at this point) currently in LISP are felt to be > adequate for the needs of the on-going early stages of deployment; > experience will indicate when improvements are required (within the > constraints of the conflicting goal given above). > > For more on LISP's security philosophy; see > [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid > out in some detail. > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 12] > > Internet-Draft LISP Introduction July 2014 > > > 7. Initial Applications > > {{Suggested by editors: Move this section after section 8, the > applications should not be described before LISP has been fully > described. > > {{Suggested by Noel: Reorder the whole section in popularity order?}} > > As previously mentioned, it is felt that LISP will provide even the > earliest adopters with some useful capabilities, and that these > capabilities will drive early LISP deployment. > > It is very imporant to note that even when used only for > interoperation with existing un-modified hosts, use of LISP can still > provide benefits to the site which has deployed it - and, perhaps > even more importantly, can do so to both sides. This characteristic > acts to further enhance the utility for early adopters of LISP. > > Note also that this section only lists some early applications and > benefits. See [I-D.ietf-lisp-perspective], in the Section "Goals of > LISP", for a more extensive discussion of some of what LISP might > ultimately provide. > > 7.1. Provider Independence > > Provider independence (i.e. the ability to easily change one's > Internet Service Provider) is a good example of the utility of > separating location and identity. > > To limit global routing table size addresses need to be aggregated. > To that aim networks can use provider aggregatable addresses > ([RFC4116]) which means that the IP prefixes of networks are sub- > prefixes of their provider. This solutions allows to reduce > scalability issues of the global routing table but it means that when > a network switches providers it has to re-number all its devices > which is known to be complex in current networks [RFC5887]. > > Having separate namespaces for location and identity greatly reduces > the problems involved with re-numbering; an organization which moves > retains its EIDs (which are how most other parties refer to its > nodes), but is allocated new RLOCs, and the mapping system can > quickly provide the updated mapping from the EIDs to the new RLOCs. > > 7.2. Multi-Homing > > {{Suggested by editors: This section should be extended, it is > unclear the benefits that LISP brings to multihoming (.e.g, traffic > engineering, decoupled multihoming from the data-plane). > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 13] > > Internet-Draft LISP Introduction July 2014 > > > Multi-homing is another place where the value of separation of > location and identity became apparent. There are several different > sub-flavours of the multi-homing problem - e.g. depending on whether > one wants open TCP connections to keep working, etc - and other axes > as well (e.g. site multi-homing versus host multi-homing). > > In particular, for the 'keep open connections up' case, without > separation of location and identity, with most currently deployed > implementations, the only currently feasible approach is to use > provider-independent addressses - which moves the problem into the > global routing system, with attendant costs. This approach is also > not really feasible for host multi-homing. > > 7.3. Traffic Engineering > > {{Suggestion by editors: Merge this section with the previous one, TE > is not practical without multihoming}} > > {{Needs a fix - not sure what.}} > > Traffic engineering (TE) [RFC3272], desirable though this capability > is in a global network, is currently somewhat problematic to provide > in the Internet. The problem, fundamentally, is that this capability > was not forseen when the Internet was designed, so the support for it > via hacks is neither clean, nor flexible. > > TE is, fundamentally, a routing issue. However, the current Internet > routing architecture, which is basically the Baran design of fifty > years ago [Baran] (a single large, distributed computation), is ill- > suited to provide TE. The Internet seems a long way from adopting a > more-advanced routing architecture, although the basic concepts for > such have been known for some time. [RFC1992] > > Although the identity-location mapping layer is thus a poor place, > architecturally, to provide TE capabilities, it is still an > improvement over the current routing tools available for this purpose > (e.g. injection of more-specific routes into the global routing > table). > > In addition, instead of the entire network incurring the costs > (through the routing system overhead), when using a mapping layer to > provide TE, the overhead is limited to those who are actually > communicating with that particular destination. > > LISP includes a number of features in the mapping system to support > TE. (described in Section 8.2, "Control Plane - Mapping System > Overview", below); more details about using LISP for TE can be found > in [I-D.farinacci-lisp-te]. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 14] > > Internet-Draft LISP Introduction July 2014 > > > Also, a number of academic papers have explored how LISP can be used > to do TE, and how effective it can be. See the online LISP > Bibliography ([Bibliography]) for information about them. > > 7.4. Routing > > {{Suggestion by editors: Remove this section, LISP is not a routing > protocol.}} > > Multi-homing and Traffic Engineering are both, in some sense, uses of > LISP for routing, but there are many other routing-related uses for > LISP. > > One of the major original motivations for the separation of location > and identity in general, and thus LISP, was to reduce the growth of > the routing tables in the "Internet core", the part where routes to > _all_ ultimate destinations must be available. LISP is expected to > help with this; for more detail, see Section 15.4, "LISP and Core > Internet Routing", below. > > LISP may also have more local applications in which it can help with > routing; see, for instance, [CorasBGP]. > > 7.5. Mobility > > {{Suggestion by editors: Remove this section, mobility is not in > charter.}} > > Mobility is yet another place where separation of location and > identity is a key part of a clean, efficient and high-functionality > solution. Considerable experimentation has been completed on doing > mobility with LISP. > > The mobility provided by LISP allows active sessions to survive moves > (provided of course that there is not a period of inaccessibility > which exceeds a timeout). LISP mobility also will typically have > better packet stretch (i.e. increase in path length) compared to > traditional mobility schemes, which use a home agent. > > 7.6. Traversal Across Alternate IP Versions > > Note that LISP inherently supports intermixing of various IP versions > for packet carriage; IPv4 packets might well be carried in IPv6, or > vice versa, depending on the network's configuration. > > This capability allows an island of operation of one type to be > automatically tunneled over a stretch of infrastucture which only > supports the other type. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 15] > > Internet-Draft LISP Introduction July 2014 > > > 7.7. Virtual Private Networks > > {{Suggestion by editors: Remove this section, not covered by any WG > document}} > > L2 and L3 {{Need to add text here - This used to be part of 'Local' > below, but we decided this was so important it deserved its own > section. Maybe move this up further, as it seems to be the most > important 'early adopter' application?}} > > The mapping-and-encapsulation nature of LISP makes it a perfect > candidate for VPN solutions. In this case, private parts of the VPN > form LISP sites and the IP addresses of devices in the private parts > are composing EID spaces. The interconnection between the LISP sites > is the public network and IP addresses in the interconnection compose > the RLOC space. A major advantage of using LISP to construct VPN > resides in the simplicity of the configurations: each xTR (i.e., VPN > end) is configured to query the mapping system to retrieve mappings > making the glue between the public (RLOC space) and the private (EID > space) of the VPN. > > This includes support of multi-tenancy where several private networks > can be carried over the same underlayer network. Thanks to the > instance-id field, multi-tenant network can even use the exact same > addresses as the xTR distinguishes the tenant based on the value of > the instance-id. The multiple address family support in LISP > mappings also allows to build private networks using a different > addressing family than the carrier (e.g., IPv6 over IPv4). > > 7.8. Local Uses > > {{Suggestion by editors: Remove this section. The section contains a > general discussion about the applicability of LISP in intra-domain > scenarios, however it does not describe any specific application.}} > > LISP has a number of use cases which are within purely > organizationally-local contexts, i.e. not in the larger Internet. > These fall into two categories: uses seen on the Internet (above), > but here on a private (and usually small scale) setting; and > applications which do not have a direct analog in the larger > Internet, and which apply only to local deployments. > > Among the former are multi-homing and IP version traversal. {{This > was marked to be deleted - why? The next part doesn't make sense > without this first?}} > > Among the latter class, non-Internet applications which have no > analog on the Internet, are the following example applications: > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 16] > > Internet-Draft LISP Introduction July 2014 > > > virtual machine mobility in data centers; non-IP EID types such as L2 > MAC addresses, or application specific data. > > Several of the applications listed in this section are the ones which > have been most popular for LISP in practise; these include virtual > networks, and virtual machine mobility. > > These often show a synergistic tendency, in that a site which > installs LISP to do one, often finds that then becomes a small matter > to use it for the second. Given all the things which LISP can do, it > is hoped that this synergistic effect will continue to expand LISP's > uses. > > {{Preceeding paragraphs should probably get moved up into VPN > section?}} > > 8. Major Functional Subsystems > > {{Suggestion by editors: This section should appear before since it > describes key aspects of LISP (e.g., LISP decoupled control and data- > plane).}} Yes, possibly where the first figure is. > LISP has two major functional sub-systems: the xTRs which form the > data-plane of LISP; and the mapping system which forms the control > plane that maintains and distributes the mapping database. > > The purpose and operation of each is described at a high level below, > and then, later on, in a fair amount of detail, in separate sections > on each (Section 12 and Section 13). > > 8.1. Data Plane - xTRs Overview > > {{Suggestion by editors: Extend this section, it misses key LISP > data-plane aspects, such as the map-cache.}} > > xTRs are routers that have been augmented with extra functionality in > both the data and control planes. The data plane functions in ITRs > include deciding which packets need to be given LISP processing > (since packets to non-LISP hosts may be sent as they are); i.e. > looking up the mapping; encapsulating (wrapping) the packet; and > sending it to the ETR. > > This encapsulation is done using UDP [RFC0768], along with an > additional outer IP header (to hold the source and destination > RLOCs). To the extent that traffic engineering features are in use > for a particular EID, the ITRs implement them as well. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 17] > > Internet-Draft LISP Introduction July 2014 > > > In the ETR, the data plane simply decapsulates (unwraps) the packets, > and forwards the it to the destination. > > Control plane functions in ITRs include: asking for EID-to-RLOC > mappings via Map-Request packets; handling the returning reply > control messages (i.e., Map-Reply packets), which contain the EID-to- > RLOC mapping; managing the local mapping cache and checking for the > reachability of destination ETR's RLOCs. > > In the ETR, control plane functions include participating in the > reachability tests (see Section 16.4); interacting with the mapping > sub-system to let it know what mapping this ETR can provide (see > Section 8.2.2); and answering Map-Request packets from ITRs for those > mappings. > > 8.1.1. Mapping Cache Performance > > {{Suggestion by editors: Push this section further in the document, > the cache performance is not a "Major LISP subsystem"}} > > As mentioned, studies have been performed to verify that caching > mappings in ITRs is viable, in practical engineering terms. These > studies not only verified that such caching is feasible, but also > provided some insight for designing ITR "mapping caches". > > Briefly, they took lengthy traces of all packets leaving a large > site, over a period of a week or so, and used those to drive > simulations which showed how many mappings would be required. It > also allowed analysis of how much control traffic (for loading needed > mappings) would result, using various cache sizes and replacement > algorithms. These studies provide an insight into how well LISP can > be expected to perform, and scale, over time. > > A more extended look at the results us given below, in Section 12.9, > "xTR Mapping Cache Performance". > > 8.2. Control Plane - Mapping System Overview > > {{Suggestion by editors: Rewrite: Replace EID block terminology > (along with its description) with the very common term "prefix". > Describe Map-Request/Map-Reply LISP signaling messages.}} > > The mapping system's entire purpose is to give ITRs on-demand access > to the mapping database, which is a distributed, and potentially > replicated, database which holds mappings between EIDs (identity) and > RLOCs (location), along with needed ancillary data (e.g. lifetimes). > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 18] > > Internet-Draft LISP Introduction July 2014 > > > To be exact, it contains mappings between EID blocks and RLOCs (the > block size is given explicitly, as part of the syntax). Support for > blocks is both for minimizing the administrative configuration > overhead, as well as for operational efficiency; e.g. when a group of > EIDs are behind a single xTR. In IP blocks are delimited by their IP > prefix. > > However, the block may be, and sometimes is, as small as a single > EID. However, since mappings are only loaded upon demand, if smaller > blocks become predominant, then the increased size of the overall > database is far less problematic than if the Internet's routing > tables came to be dominated by such small entries. > > A particular EID (or EID block) may be associated to than one RLOC, > and may change the association with time. > > Also, in general, throughout LISP, the address family of EIDs and > RLOCs is explicitly mentioned in control packet. > > Finally, the mapping from an EID (or EID block) contains not just the > RLOC(s), but also (for each RLOC for any given EID entry) priority > and weight fields (to allow allocation of load between several RLOCs > at a given priority); this allows a certain amount of traffic > engineering to be accomplished with LISP. > > 8.2.1. Mapping System Organization > > {{Suggestion by editors: Rewrite: Describe key Mapping System > components: Map-Server/Map-Resolver}} > > The mapping system is split into three functional sub-systems. > > The first is the actual mappings themselves, collectively the mapping > database; they are held by the ETRs, and an ITR which needs a mapping > gets it (effectively) directly from the ETR. This co-location of the > authoritative version of the mappings, and the forwarding > functionality which it describes, is an instance of fate-sharing. > [Clark] > > To find the appropriate ETR(s) to query for the mapping, the second > two sub-systems form an indexing system, itself also based on a > distributed, potentially replicated database. It provides > information on which ETR(s) are authoritative sources for the various > EID-to-RLOC mappings which are available. The two sub-systems which > form it are the client interface sub-system, and indexing sub-system > (which holds and provides the actual information). > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 19] > > Internet-Draft LISP Introduction July 2014 > > > 8.2.2. Interface to the Mapping System > > {{Suggestion by editors: has been rewritten: This section should > appear earlier since it describes key LISP components (Map-Request/ > Map-Reply/Map-Server/Map-Resolver}} > > The client interface to the indexing system from an ITR's point of > view is not with the indexing sub-system directly; rather, it is > through the Map-Resolvers (MRs) and Map-Servers (MSs). > > To obtain the mapping for an EID, the ITRs sends Map-Request packet > to an MR. The MR then uses the indexing sub-system to allow it to > forward the Map-Request to an appropriate Map-Server (MS), which in > turn sends the Map-Request on to the appropriate ETR. The latter is > authoritative for the actual mappings for the EID. > > The ETR then sends the mappings for that EID in the form of aMap- > Reply packets, which is sent directly to the ITR, without passing > through the indexing sub-system and MR. The details of the indexing > sub-system are thus hidden from the ITRs. > > Note that in proxy mode, the MS replies on behalf of the ETR. When > this the case, the map-replies is tagged to indicate that the answer > is not delivered from the authoritative ETR but from the MS instead. > > The interface to the indexing system from an ETR's point of view is > made through MSes. ETRs send Map-Register packets to their > designated MSes. The effect of a Map-Register is to inform the MS > about the mappings maintained by ETRs such that the MS can transmit > the Map-Requests is receives to the appropriate ETRs. > > The MS optionally replies Map-Register packets with a Map-Notify > packet to confirm the registration. The details of the indexing sub- > system are thus likewise hidden from ETRs. > > The fact that the details of the indexing sub-system are entirely > hidden from xTRs gives considerably flexibility to this aspect of > LISP. As long as any potential indexing sub-system can track where > mappings are, it could potentially be used; this would allow the > actual indexing sub-system to be replaced without needing to modify > the xTRs. > > 8.2.3. Indexing Sub-system > > {{suggestion by editor: rename the section to "DDT"}} I think this section should briefly describe both ALT (mostly by reference to RFC 6836) and DDT (by reference to LISP-DDT, with way fewer details on DDT than in the current document). "Indexing System" (as a component of the mapping system, together with the mapping database) may be a good name for this section. > The current indexing sub-system is the Delegated Database Tree (DDT), > which is conceptually similar to DNS ([I-D.ietf-lisp-ddt], > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 20] > > Internet-Draft LISP Introduction July 2014 > > > [RFC1034]). DDT replaces the earlier LISP+ALT indexing sub-system > ([RFC6836]). The seamless migration to DDT while LISP+ALT was > previously used validated the concept of having a client-interface > sub-system between the indexing sub-system, and the clients. > > 8.2.3.1. DDT Overview > > Conceptually, DDT is similar to the DNS, in DDT the delegation of the > EID namespace is instantiated as a delegation hierarchy, a tree of > DDT nodes, starting with the root DDT node. Each vertex is > responsible for a block of the EID namespace. > > The root node is responsible for the entire EID space; any DDT node > can delegate part(s) of its EID block to child DDT node(s). The > child node(s) can in turn further delegate (necessarily smaller) > blocks of namespace to their children, through as many levels as are > needed (for operational, administrative, etc, needs). > > Just as with DNS, any particular vertex in the DDT delegation tree > may be instantiated in one or more DDT servers. Multiple (redundant) > servers for a given node would be used for reasons of performance, > reliability, and robustness. Obviously, all the servers which > instantiate a particular nodes in the tree have to have identical > data about that node. > > 8.2.3.2. Use of DDT by MRs > > An MR which wants to find a mapping for a particular EID first > interacts with the DDT servers which instantiate the nodes of the > LISP delegation hierarchy tree, discovering (by querying the servers > for information about DDT nodes) the chain of delegations which cover > that EID. Eventually it is directed to an MS, which is servicing an > ETR which is authoritative for that EID. > > Also, again like DNS, MRs may cache information they receive about > the delegations in the delegation tree. This means that once an MR > has been in operation for a while, it will usually have much of the > delegation information cached locally (especially the top levels of > the delegation tree). This allows them, when passed a request for a > mapping by an ITR, to usually forward the mapping request to the > appropriate MS without having to interact with all the DDT servers on > the path down the delegation tree, in order to find any particular > mapping. > > Thus, a typical resolution cycle would usually involve looking at > some locally cached delegation information, perhaps loading some > missing delegation entries into their delegation cache, and finally > sending the Map-Request to the appropriate MS. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 21] > > Internet-Draft LISP Introduction July 2014 > > > It should also be noted that the delegation tree is fairly static, > since it reflects EID block allocations, which are themselves fairly > static. This stability has several important consequences. First, > it increases the performance of the mapping system, since the sub- > system almost never needs to be re-queried for information about > intermediate vertices. {{comment from editor: does not understand > the next sentence...}}Second, it is not necessary to include a > mechanism to find out-dated delegations. [LISP-TREE] > > This contrasts with the mappings, which may change at a high rate - > changes which have no impact on the indexing sub-system. The > potentially high dynamics of mappings explains why mappings are > delivered directly from ETRs (or MSes in proxy mode) to ITRs and > hence not cached at the MR level. LISP is designed to make sure that > changes in the mappings are detected and acted upon fairly quickly; > this allows LISP to provide a number of capabilities, such as > mobility. > > 9. Examples of operation > > To aid in comprehension, a few examples are given of user packets > traversing the LISP system. The first shows the processing of a > typical user packet which is LISP forwarded, i.e. what the vast > majority of user packets will see. The second shows what happens > when the first packet to a previously-unseen ultimate destination (at > a particular ITR) is to be processed by LISP. > > 9.1. An Ordinary Packet's Processing > > {{Suggestion by editors: This section should be earlier in the > document structure, examples are important -particularly for > engineers- to explain how systems work}} > > This case follows the processing of a typical , {{comment from > editors: text missing}} when the packet has made its way through the > local site to an ITR, which in this case is a border router for the > site, the border router looks up the destination address - an EID - > in its local mapping cache. For EIDs which are IP addresses, this > lookup uses the IP longest prefix matching algorithm. > > It finds a mapping, which instructs it to wrap the packet in an outer > header - an IP packet, containing a UDP packet which contains a LISP > header - and then the user's original packet (see Section 12.2 for > the reasons for this particular choice). The destination address in > the outer header is set by the ITR to the RLOC of the destination > ETR. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 22] > > Internet-Draft LISP Introduction July 2014 > > > The encapsulated packet is then sent off through the RLOC space > (e.g., Internet), using normal Internet routing. > > On arrival at the destination ETR, the ETR will notice that it is > listed as the destination in the outer header. It will examine the > packet, detect that it is a LISP packet, and unwrap it. It will then > examine the header of the user's original packet, and forward it > internally, through the local site, to the ultimate destination. > > At the ultimate destination, the packet will be processed, and may > produce a return packet, which follows the exact same process in > reverse - with the exception that the roles of the ITR and ETR are > swapped. > > 9.2. A Mapping Cache Miss > > {{Suggestion by editors: (same as previous section)}} > > If a host sends a packet, and it gets to the ITR, and the ITR > determines that it does not yet have a mapping cache entry which > covers that destination EID, then additional processing ensues; it > has to look up the mapping in the mapping system (as previously > described in Section 6.2). > > The overall processing is shown below, in Figure 2: > > ----- ----- > | | 3 | | > Map Resolver | | -------> | | Map Server > | | | | > ----- ----- > ^ | > Key: | | > | | > -- = Control | | > == = Data | | > 2 | 5 | 4 > | --- | > Host A | / \ | Host B > | |_ \ V > ----- ----- \ ----- ----- > | | 1 | | 6 | | 7 | | > | | =====> | ITR | =======> | ETR | =====> | | > | | | | | | | | > ----- ----- ----- ----- > > Figure 2: Packet flow with missing mapping > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 23] > > Internet-Draft LISP Introduction July 2014 > > > 1. Source-EID sends packet (to Dest-EID) to ITR > > 2. ITR sends Map-Request to Map-Resolver > > 3. Map-Resolver delivers Map-Request to Map-Server > > 4. Map-Server delivers Map-Request to ETR > > 5. ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping > > 6. ITR uses mapping to encapsulate to ETR; sends user packet to ETR > > 7. ETR decapsulates packet, delivers to Dest-EID > > The ITR first sends a Map-Request packet, giving the destination EID > it needs a mapping for, to its MR. The MR will look in its cache of > delegation information to find the vertex which is the most specific > in the delegation tree for that destination EID . If it does not > have the address of an appropriate MS, it will query the DDT system, > recursively if need be, in order to eventually find the address of > such an MS. > > When it has the MS's address, it will send the Map-Request on to the > MS, which then usually sends it on to an appropriate ETR. The ETR > sends a Map-Reply to the ITR which needs the mapping; from then on, > processing of user packets through that ITR to that ultimate > destination proceeds as above. > > To the best of our knowledge, in all LISP implementations, the > original user packet will have been discarded, and not queued waiting > for the mapping to be returned. When the host retransmits such a > packet, the mapping will be there, and the packet will be forwarded. > Alternatively, it might have been forwarded using a PITR to avoid > being dropped (Section 6.4). > > 10. Part II > > {{comment from editors: is that the role of an introductory document > to enter in such level of details and discuss (mostly) all fields of > the protocol? }} No. It should just describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a *basis* for discussion about the details of the LISP protocols. > 11. Design Approach > > {{Suggestion by editors: Remove this section, it does not describe/ > discuss anything relevant, it is only providing a reference to > another non-WG document.}} > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 24] > > Internet-Draft LISP Introduction July 2014 > > > Before describing LISP's components in more detail below, it it worth > pointing out that what may seem, in some cases, like odd (or poor) > design approaches do in fact result from the application of a > thought-through, and consistent, design philosophy used in creating > them. {{Subjective: maybe JMH, Dino can help with better words?}} > > This design philosophy is covered in detail in > [I-D.ietf-lisp-perspective], Section "Design"), and readers who are > interested in the 'why' of various mechanisms should consult that; > reading it may make clearer the reasons for some engineering choices > in the mechanisms given here. > > 12. xTRs > > As mentioned above (in Section 8.1), xTRs are the essential LISP data > plane elements. This section explores some advanced topics related > to xTRs. > > {{Suggestion by editors: remove next paragraph, brings nothing)}} > > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that traceroute works when xTRs are involved. > > 12.1. When to Encapsulate > > An ITR knows that an ultimate destination is running LISP (remember > that the actual destination machine itself probably knows nothing > about LISP), and thus that it should perform LISP processing on a > packet (including potential encapsulation) if it has an entry in its > local mapping cache that covers the destination address (it is then > called an EID). > > Conversely, if the cache contains a negative entry (indicating that > the ITR has previously attempted to find a mapping that covers this > EID, and it has been informed by the mapping system that no such > mapping exists), it knows the ultimate destination is not running > LISP, and the packet can be forwarded natively (i.e. not LISP- > encapsulated). > > Note that the ITR cannot simply depend on the appearance, or non- > appearance, of the destination in the routing tables in the Internet > core, as a way to tell if a destination is a LISP node or not. That > is because mechanisms to allow interoperation of LISP sites and > legacy sites necessarily involve advertising LISP sites' EIDs into > the Internet core; in other words, LISP sites which need to > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 25] > > Internet-Draft LISP Introduction July 2014 > > > interoperate with legacy nodes will appear in the Internet core > routing tables, along with non-LISP sites. > > 12.2. UDP Encapsulation Details > > Use of UDP (instead of, say, a LISP-specific protocol number) was > driven by the fact that many routers and middle boxes filter out > unknown protocols, so adopting a non-UDP encapsulation would have > compromised the initial deployment of LISP. > > The UDP source port used for encapsulating packet is computed with a > 5-way hash of the original source and destination in the inner > header, along with the ports, and the protocol. This is because many > ISPs use multiple parallel paths (so-called Equal Cost Multi-Path), > and load-share across them. Using such a hash in the source-port in > the outer header both allows LISP traffic to be load-shared, and also > ensures that packets from individual connections are delivered in > order (since most ISPs try to ensure that packets for a particular > flow follow a single path, and hence do not become disordered). > > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value ([Saltzer]). > {{Suggestion by editors: not sure that next statement is correct}} In > most exising hardware, computing such a checksum (and checking it at > the other end) would also present a major load, for no benefit. > > 12.3. Header Control Channel > > {{Suggestion by editors: Rewrite this section to improve readability, > use standard terminology (e.g., Cache Coherence/Reachability instead > of "Header Control Channel"). Split the mechanisms depending on its > goal (cache coherence/reachability) and describe them under the same > context.}} > > LISP provides a multiplexed channel in the encapsulation header. It > is mostly (but not entirely) used for control purposes. The general > concept is that the header starts with a flags field, and it also > includes two data fields, the contents and meaning of which vary, > depending on which flags are set. This allows these fields to be > multiplexed among a number of different low-duty-cycle functions, > while minimizing the space overhead of the LISP. > > 12.3.1. Mapping Versioning > > One important use of the multiplexed control channel is mapping > versioning; i.e. the discovery of when the mapping cached in an ITR > is outdated. To allow an ITR to discover this, identifying sequence > numbers are applied to different versions of a mappping [RFC6834]. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 26] > > Internet-Draft LISP Introduction July 2014 > > > This allows an ITR to easily discover when a cached mapping has been > updated by a more recent variant. > > Version numbers are available in control messages (Map-Replies), but > the initial concept is that to limit control message overhead, the > versioning mechanism should primarily use the multiplexed user data > header control channel. > > Versioning can operate in both directions: an ITR can advise an ETR > what version of a mapping it is currently using (so the ETR can > notify it if there is a more recent version), and ETRs can let ITRs > know what the current mapping version is (so the ITRs can request an > update, if their copy is outdated). > > 12.3.2. Echo Nonces > > Another important use of the header control channel is for a > mechanism known as the Nonce Echo, which is used as an efficient > method for ITRs to check the reachability of neighbour ETRs. > > Basically, an ITR which has to determine that an ETR is up, and > reachable, sends a nonce to that ETR, carried in the encapsulation > header; when that ETR (also acting as an ITR) sends some other user > data packet back to the ITR (acting in turn as an ETR), that nonce is > carried in the header of that packet, allowing the original ITR to > confirm that its packets are reaching that ETR. > > Note that a lack of a response is not necessarily proof that > something has gone wrong - but it strongly 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. (See Section 16.5 for more > about Echo Nonces.) > > 12.3.3. Instances > > {{Suggestion by editors: Move and extend this section: - Instance ID > is not a cache-coherence/reachability algorithm. Describe where and > what is the Instance ID field Explain its applications}} > > The LISP data-plane header is also used to support VPN and multi- > tenant networks. Since there is only one destination UDP port used > for carriage of user data packets, and the source port is used for > multiplexing, there is no other way to differentiate among different > destination EID spaces (which are often overlapped in VPNs and multi- > tenant networks). > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 27] > > Internet-Draft LISP Introduction July 2014 > > > 12.4. Probing > > RLOC-Probing is a mechanism method that an ITR can use to determine > with that an ETR is up and reachable from the ITR. As a side- > benefit, it gives RTT estimates. > > To probe the reachability of an RLOC, an ITR sends a specially marked > Map-Request directly to the ETR it wishes information about; that ETR > sends back a specially marked Map-Reply. A Map-Request message and a > Map-Reply message are used, rather than a special probing control- > message pair, because as a side-benefit the ITR can discover if the > mapping has been updated since it cached it. > > {{Suggestion from editors: remove the following sentence as it is not > motivated by strong arguments}} The probing mechanism is rather > heavy-weight and expensive (compared to mechanisms like the Echo- > Nonce), since it costs a control message from each side, so it should > only be used sparingly. > > If the number of active neighbour ETRs of the ITR is large, use of > RLOC-Probing to check on their reachability will result in > considerable control traffic; such control traffic has to be spread > out to prevent a load peak. > > Obviously, if RLOC-Probing is the only mechanism being used to detect > unreachable neighbour ETRs, the rate at which RLOC-Probing is done > will control the timeliness of the detection of loss of reachability. > There is thus a tradeoff between overhead and responsiveness, > particular when an ITR has a large fanout of neighbour ETRs. > > 12.5. Mapping Lifetimes and Timeouts > > {{Suggestion by editors: Remove this section, TTL is a simple well- > known concept, we suggest to include a sentence (and hence remove > this section) in the control-plane section stating that mappings > include a TTL. > > Mappings come with a Time-To-Live, which indicate how long the > creator of the mapping expects them to be useful for. > > Mappings might also be discarded before the TTL expires, depending on > what strategies the ITR is using to maintain its cache; if the > maximum cache size is fixed, or the ITR needs to reclaim memory, > mappings which have not been used recently may be discarded. (After > all, there is no harm in so doing; a future reference will merely > cause that mapping to be reloaded.) > > {{Contents may change before TTL expires?}} > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 28] > > Internet-Draft LISP Introduction July 2014 > > > 12.6. Mapping Gleaning in ETRs > > {{Suggestion by editors: Remove this section, gleaning is discouraged > since it rises many security concerns.}} > > As an optimization to the mapping acquisition process, ETRs are > allowed to glean mappings from incoming user data packets, and also > from incoming Map-Request control messages. This is not secure, and > so any such mapping must be verified by sending a Map-Request to get > an authoritative mapping. > > The value of gleaning is that most communications are two-way, and so > if host A is sending packets to host B (therefore needing B's > EID->RLOC mapping), very likely B will soon be sending packets back > to A (and thus needing A's EID->RLOC mapping). Without gleaning, > this would sometimes result in a delay, and the dropping of the first > return packet; this is felt to be very undesirable. > > 12.7. MTU Issues > > Several mechanisms have been proposed for dealing with packets which > are too large to transit the path from a particular ITR to a given > ETR. > > In one, called the stateful approach, the ITR keeps a per-ETR record > of the maximum size allowed, and sends an ICMP Too Big message to the > original source host when a packet which is too large is seen. > > In the other, referred to as the stateless approach, for IPv4 packets > without the DF bit set, too-large packets are fragmented, and then > the fragments are forwarded; all other packets are discarded, and an > ICMP Too Big message returned. > > 12.8. Security of Mapping Lookups > > {{Suggestion from editors: would remove all what is related to > security and instead put a small summary in the security section and > reference the threats document}} agree. > LISP provides an optional mechanism to secure the obtaining of > mappings by an ITR. [I-D.ietf-lisp-sec] It provides protection > against attackers generating spurious Map-Reply messages (including > replaying old Map-Replies), and also against over-claiming attacks > (where a malicious ETR by claims EID-prefixes which are larger than > what have been actually delegated to it). > > In summary, the ITR provides a One-Time Key with its Map-Request; > this key is used by both the MS (to sign an affirmation that it has > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 29] > > Internet-Draft LISP Introduction July 2014 > > > delegated that EID block to that ETR), and indirectly by the ETR (to > sign the mapping that it is returning to the ITR). > > The specification for LISP-SEC suggests that the ITR-MR stage be > cryptographically protected, and indicates that the existing > mechanisms for securing the ETR-MS stage are used to protect Map- > Rquests also. It does assume that the channel from the MR to the MS > is secure. > > 12.9. ITR Mapping Cache Performance > > As mentioned previously (Section 8.1.1, a substantial amount of > simulation work has been performed to predict, and understand, the > performance of the mapping cache in xTRs. > > Briefly, however, the first, [Iannone], was performed in the very > early stages of the LISP effort, to verify that that caching approach > was feasible. > > Packet traces of all traffic over the external connection of a large > university over a week-long period were collected; simulations driven > by these recording were then performed. A variety of control > settings on the cache were used, to study the effects of varying the > settings. > > First, the simulation gave the cache sizes that would result from > such a cache design: it showed that the resulting cache sizes ranged > from 7,500 entries, up to about 100,000 (depending on factors such as > traffic and entry retention time). Using some estimations as to how > much memory mapping entries would use, this indicated cache sizes of > between roughly 100 Kbytes and a few Mbytes. > > Of more interest, in a way, were the results regarding two important > measurements of the effectiveness of the cache: i) the hit ratio > (i.e. the share of references which could be satisfied by the cache), > and ii) the miss rate (since control traffic overhead is one of the > chief concerns when using a cache). These results were also > encouraging: miss (and hence lookup) rates ranged from 30 per minute, > up to 3,000 per minute. > > Significantly, this was substantially lower than the amount of > observed DNS traffic, which ranged from 1,800 packets per minute up > to 15,000 per minute. The results overall showed that using a > demand-loaded cache was an entirely plausible design approach: both > cache size, and the control plane traffic load, were definitely > feasible. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 30] > > Internet-Draft LISP Introduction July 2014 > > > The second, [Kim], was in general terms similar, except that it used > data from a large ISP, one with about three times as many users as > the previous study. It used the same cache design philosophy (the > cache size was not fixed), but slightly different, lower, retention > time values. > > The results were similar: cache sizes ranges from 20,000 entries to > roughly 60,000; the miss rate ranged from very roughly 400 per minute > to very roughly 7,000 per minute, similar to the previous results. > > Finally, a third study, [CorasCache], examined the effect of using a > fixed size cache, and a purely Least Recently Used (LRU) cache > eviction algorithm (i.e. no timeouts). It also tried to verify that > models of the performance of such a cache (using previous theoretical > work on caches) produced results that conformed with actual empirical > measurements. > > It used yet another set of packet traces; using a cache size of > around 50,000 entries produced a miss rate of around 1x10-4; again, > definitely viable, and in line with the results of the other studies. > > 13. The Mapping System > > {{Suggestion by editors: This section is somewhat redundant with > respect to section 8.2, we suggest to move this section to Part I > since it provides some missing details.}} > > As discussed already in Section 8.2, the LISP mapping system is an > important part of LISP's control plane: it i) maintains the database > of mappings between EIDs, and the RLOCs at which they are to be > found, and ii) provides those mappings to ITRs which request them, so > that the ITRs can send traffic for a given EID to the correct RLOC(s) > for that EID. > > [RFC1034] has this to say about the DNS name to IP address database > and mapping system: > > "The sheer size of the database and frequency of updates suggest > that it must be maintained in a distributed manner, with local > caching to improve performance. Approaches that attempt to > collect a consistent copy of the entire database will become more > and more expensive and difficult, and hence should be avoided." > > and this observation applies equally to the LISP mapping database and > mapping system. > > To briefly recap, the mapping system is split into three parts: i) an > indexing sub-system, which keeps track of where all the mappings are > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 31] > > Internet-Draft LISP Introduction July 2014 > > > kept; ii) the interface to the indexing system (which remains the > same, even if the actual indexing system is changed); and iii) the > mappings themselves (collectively, the mapping database), the > authoritative copies of which are always held by ETRs. > > 13.1. The Mapping System Interface > > As mentioned in Section 8.2.2, both of the interfaces to the mapping > system (from ITRs, and ETRs) are standardized, so that the more > numerous xTRs do not have to be modified when the mapping indexing > sub-system is changed. > > This section describes the interfaces in a little more detail; for > details, see [RFC6833]. > > 13.1.1. Map-Request Messages > > {{Suggestion from editors: should come much earlier as it is an > essential message in LISP}} > > The Map-Request message contains a number of fields, the two most > important of which are the requested EID block identifier (remember > that individual mappings may cover a block of EIDs, not just a single > EID), and the Address Family Identifier (AFI) for that EID block. > > Other important fields are the source EID (and its AFI), and one or > more RLOCs for the source EID, along with their AFIs. The source EID > and RLOCs allow ETRs to customize their answer. > > Finally, the message includes a long nonce, for simple, efficient > protection against offpath attackers and a variety of other fields > and control flag bits. > > 13.1.2. Map-Reply Messages > > {{Suggestion from editors: should come much earlier as it is an > essential message in LISP}} > > The Map-Reply message looks similar, except it includes the mapping > entry for the requested EID(s), which contains one or more RLOCs and > their associated data. Note that the reply may cover a larger block > of the EID namespace than the request; most requests will be for a > single EID, the one which prompted the query. > > If there are no mappings available at all for the EID(s) requested, a > Negative Map-Reply message will be returned. This is a Map-Reply > message with flag bits set to indicate that fact. > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 32] > > Internet-Draft LISP Introduction July 2014 > > > For each RLOC in the entry, there is the RLOC, its AFI, priority and > weight fields (see Section 8.2), and multicast priority and weight > fields (see Section 14). > > 13.1.2.1. Solicit-Map-Request Messages > > Solicit-Map-Request (SMR) messages are actually not another message > type, but a variant of Map-Request messages. They include a special > flag which indicates to the recipient that it should send a new Map- > Request message, to refresh its mapping, because the ETR has detected > that the one it is using is out-dated. > > SMR's, like most other control traffic, should be rate-limited. > > 13.1.3. Map-Register and Map-Notify Messages > > {{Suggestion by editors: As noted by the author add a paragraph > describing how a xTR de-registers an EID-to-RLOC mapping.}} > > {{Suggestion by editors: add a small paragraph to explain what Map- > Registers are used for}} > > The Map-Register message contains one or several mapping records, > each with an individual Time-To-Live (TTL). Each of the records > contains an EID (potentially, a block of EIDs) and its AFI, a version > number for this mapping (see Section 12.3.1 and a list of RLOCs and > their AFIs. > > {{Suggestion by editors: do not understand the following paragraph}} > Each RLOC entry also includes the same data as in the Map-Replies > (i.e. priority and weight); this is because in some circumstances it > is advantageous to allow the MS to proxy reply on the ETR's behalf to > Map-Request messages, and the MS needs this information when it does > so. > > Map-Notify messages have the exact same contents as Map-Register > messages; they are purely acknowledgements. > > The entire interaction is authenticated by use of a shared key, > configured in the MS and ETR. Although the protocol does already > allow for replacement of the encryption algorithm, it does not > support automated key management (although it appears to fall under > the exclusions in [RFC4107]). > > LISP does not specify messages for de-registering an association with > a MS. The de-registration is hence ensured by the expiration of a > timer: if a MS does not receive Map-Register messages within given > timeout, it de-register the association. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 33] > > Internet-Draft LISP Introduction July 2014 > > > 13.2. The DDT Indexing Sub-system > > {{Suggestion from the editors: this section does not add any > fundamental value to the DDT overview section, propose to remove it > to only keep the overview; too much details that should not appear in > an intro document}} Agree. See my previous comment on indexing system (and ALT and DDT). > As previously mentioned in Section 8.2.3, DDT is the current indexing > sub-system in LISP. > > The overall functioning is conceptually fairly simple; an MR which > needs a mapping starts at a server for the root DDT node (there will > normally be more than one such server available, for both performance > and robustness reasons), and through a combination of cached > delegation information, and repetitive querying of a sequence of DDT > servers, works its way down the delegation tree until it arrives at > an MS which is authoritative for the block of EID which holds the > destination EID in question. > > The interaction between MRs and DDT servers is as follow. The MR > sends to the DDT server a Map-Request control message. The DDT > server uses its data (which is configured, and static) to see whether > it is directly peered to an MS which can answer the request, or if it > has a child (or children, if replicated) which is responsible for > that portion of the EID blocks. > > If it has children configured which are responsible, it will reply to > the MR with another kind of LISP control message, a Map-Referral > message, which provides information about the delegation of the block > containing the requested EID. This step is secured via > authentication. > > The Map-Referral also gives the addresses of DDT servers for that > block and the MR can then send Map-Requests to any one (or all) of > them. In addition, the Map-Referral includes keying material for the > children, which allows any information provided by them to be > cryptographically verified. > > Control flags in the Map-Referral indicate to the querying MR whether > the referral is to another DDT server, an MS, or an ETR. {{All three? > Check}} If the former, the MR then sends the Map-Request to the child > DDT server, repeating the process. > > If the second, 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. Recall that some MS's provide Map- > Replies on behalf of an associated ETR, in so-called 'proxy mode', so > in such cases the Map-Reply will come from the MS, not the ETR. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 34] > > Internet-Draft LISP Introduction July 2014 > > > Delegations are cached in the MRs, so that once an MR has received > information about a delegation, it usually will not need to look that > up again. Once it has been in operation for a short while, there > will usually only be a limited amount of delegation information which > is has not yet asked about - probably only the last stage in a > delegation to a leaf MS. > > 13.3. Reliability via Replication > > {{Suggestion by editors: Remove this section, describes operational > practices/policies of the DDT infrastructure, this is beyond the > scope of this document.}} > > 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 (e.g. the copies > of delegation data for a particular block of namespace, in DDT > sibling servers) - 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. > > The deployed DDT system actually uses anycast [RFC4786], along with > replicated servers, to improve both performance and robustness. > > 13.4. Security of the DDT Indexing Sub-system > > {{Suggestion by editors: Remove this section, provides unnecessary > details of DDT.}} > > In summary, securing the mapping indexing system is divided into two > parts: the interface between the clients of the system (MR's) and the > mapping indexing system itself, and the interaction between the DDT > servers which make it up. > > The client interface provides only a single model, using the > canonical public-private key system (starting from a trust anchor), > in which the child's public key is provided by the parent, along with > the delegation. When the child returns any data, it can sign the > data, and the requestor can use that signature to verify the data. > This requires very little configuration in the clients. > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 35] > > Internet-Draft LISP Introduction July 2014 > > > The interface between the DDT servers allows for choices between a > number of different options, allowing the operators to trade off > among configuration complexity, security level, etc. This is based > on experience with DNSSEC ([RFC4033]), where configuration complexity > has been a major stumbling block to deployment. > > 13.5. Extended Capabilities > > {{Suggestion by editors: Remove this section, not discussed in any WG > document.}} > > In addition to the priority and weight data items in mappings, LISP > offers other tools to enhance functionality, particularly in the > traffic engineering area. > > One is requestor-specific mappings, i.e. the ETR may return different > mappings to the enquiring ITR, depending on the identity of the ITR. > This allows very fine-tuned traffic engineering, far more powerful > than routing-based TE. > > 13.6. Performance of the Mapping System > > Prior to the creation of DDT, a large study of the performance of the > previous mapping system, ALT ([RFC6836]), along with a proposed new > design called TREE (which used DNS to hold delegation information) > provided considerable insight into the likely performance of the > mapping systems at larger scale (See [LISP-TREE]). > > The basic structure and concepts of DDT are identical to those of > TREE, so the performance simulation work done for that design applies > equally to DDT. > > {{Suggestion from editors: next sentence is redundant with previous > parts of the doucment}} In that study, as with earlier LISP > performance analyses, extensive large-scale simulations were driven > by lengthy recordings of actual traffic at several major sites; one > was the site in the first study ([Iannone]), and the other was an > even large university, with roughly 35,000 users. > > The results showed that a system like DDT, which caches information > about delegations, and allows the MR to communicate directly with the > servers for the lower vertices on the delegation hierarchy based on > cached delegation information, would have good performance, with > average resolution times on the order of the MR to MS RTT. This > verified the effectiveness of this particular type of indexing > system. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 36] > > Internet-Draft LISP Introduction July 2014 > > > A more recent study, [Saucez], has measured actual resolution times > in the deployed LISP network; it took measurements from a variety of > locations in the Internet, with respect to a number of different > target EIDs. Average measured resolution delays ranged from roughly > 175 msec to 225 msec, depending on the location. > > 14. Multicast Support in LISP > > {{Suggestion by editors: Rewrite this section, it provides too many > details. Reduce it to a brief description of LISP Multicast}} > > LISP and its intrinsic separation of identity from location is well > suited for Multicast ([RFC3170], [RFC5110]), and the definition of > mappings in the current specifications already allows multicast > capability ([RFC6830]). > > {{Say something about sources.}} > > {{Suggestion by editors: remove the paragraph below, motivation for > multicast is out of the scope of this document}} > > Multicast is an important requirement, for a number of reasons: doing > multiple unicast streams is inefficient, as it is easy to use up all > the upstream bandwidth; without multicast a server can also be > saturated fairly easily in doing the unicast replication; etc. > > Since it is important for LISP to work well with multicast; doing so > has been a significant focus in LISP throughout its entire > development. > > Further very significant improvements to multicast support in LISP > are in progress; see [Improvements], Section "Multicast" for more on > them. > > 14.1. Basic Concepts of Multicast Support in LISP > > This section introduces some of the basic principles of multicast > support in LISP. > > Since group addresses name distributed collective entities, in > general they cannot have a single RLOC also. Since they usually > refer to collections of entities the notion of endpoint identity must > be > > A multicast source at a LISP site may not be able to become the root > of a distribution tree in the core if it uses its EID as its identity > for that distribution tree (i.e. a distribution tree (S-EID, G)); > that is because there may not be a route to its EID in the core > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 37] > > Internet-Draft LISP Introduction July 2014 > > > (assuming that its section of the core even supports multicast; not > all parts of the core do). > > Therefore, outside the LISP site, multicast state for the > distribution tree (S-RLOC, G) needs to be built instead, where S-RLOC > is the RLOC of the ITR that the multicast source inside the LISP site > will be sending its traffic through. > > Multicast LISP requires no packet format changes to existing > multicast packets (both control, and user data). The initial > multicast support in LISP uses existing multicast control mechanisms > exclusively; improvements currently being worked on provide LISP- > specific control mechanisms (see [Improvements]). > > 14.2. Initial Multicast Support in LISP > > {{Suggestion by editors: remove this paragraph}} > > Readers who wish to fully understand multicast support need to > consult the appropriate specifications: LISP multicast issues are > discussed in [RFC6830], Section 11; and see [RFC6831] for the full > details of current multicast support in LISP. > > With the multicast operation defined in [RFC6831]), destination group > addresses are not mapped; only the source address (when the original > source is inside a LISP site) needs to be mapped, both during > distribution tree setup, as well as actual traffic delivery. > > In other words, while LISP's mapping capability is used, at this > stage it is only applied to the source, not the destination (as with > most LISP activity). Thus, in LISP-encapsulated multicast packets in > this mode, the inner source is the EID, and the outer source is the > ITR's RLOC; both inner and outer destinations are the group's > multicast address. > > Note that this does mean that if the group is using separate source- > specific trees for distribution, there isn't a separate distribution > tree outside the LISP site for each different source of traffic to > the group from inside the LISP site; they are all grouped together > under a single source, the RLOC. > > The issue of encapsulation is complex, because if the rest of the > group outside the LISP site includes some members which are at other > LISP sites (i.e. packets to them have to be encapsulated), and some > members at legacy sites (i.e. encapsulated packets would not be > understood), there is no simple answer. (The situation becomes even > more complex when one considers that as hosts leave and join the > group, it may switch back and forth between mixed and homogenous.) > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 38] > > Internet-Draft LISP Introduction July 2014 > > > This issue is too complex to fully cover here; see Section 9.2., > "LISP Sites with Mixed Address Families", in [RFC6831], for complete > coverage of this issue. > > Basically, there are multicast equivalents of some of the legacy > interoperability mechanisms used for unicast; mPITRs and mPETRs > (multicast-capable PITRs and PETRs). When mixed groups are a > possibility, two choices are available: i) send two copies (one > encapsulated, and one not) of all traffic, or ii) employ mPETRs to > distribute non-encapsulated copies to legacy group members. > > 15. Deployment Issues and Mechanisms > > {{Suggestion by editors: Remove this section, provides unnecessary > details. Add a reference to the deployment RFC.}} > > This section discusses several deployment issues in more detail. > With LISP's heavy emphasis on practicality, much work has gone into > making sure it works well in the real-world environments most people > have to deal with. > > 15.1. LISP Deployment Needs > > As mentioned earlier (Section 5.2), LISP requires no change to almost > all existing hosts and routers. Obviously, however, one must deploy > something to run LISP. Exactly what that has to be will depend > greatly on the details of the site's existing networking gear, and > choices it makes for how to achieve LISP deployment. > > The primary requirement is for one or more xTRs. These may be > existing routers, just with new software loads, or it may require the > deployment of new devices. > > {{Suggestion by editors: next paragraph is barely understandable}} > > LISP also requires a certain amount of LISP-specific support > infrastructure, such as MRs, MSs, the DDT hierarchy, etc. However, > much of this will either i) {{for the case where you are adding a new > site using existing LISP infrastructure}} already be deployed, and if > the new site can make arrangements to use it, it need do nothing > else; or ii) those functions the site must provide may be co-located > in other LISP devices (again, either new devices, or new software on > existing ones). > > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 39] > > Internet-Draft LISP Introduction July 2014 > > > 15.2. Interworking Mechanisms > > One aspect which has received a lot of attention are the mechanisms > previously referred to (in Section 6.4) to allow interoperation of > LISP sites with so-called legacy sites which are not running LISP > (yet). > > {{Suggestion by editors: remove next paragraph as it talks about > features (NAT based transition) not covered by the WG}} > > There are two main approaches to such interworking: proxy routers > (PITRs and PETRs), and an alternative mechanism using a router with > combined NAT and LISP functionality; these are described in more > detail here. > > 15.2.1. Proxy LISP Routers > > {{Suggestion by editors: Move this section to Part I. PxTRs are an > important aspect of LISP and as such, should be described before. > Furthermore simplify it, it currently contains too many details plus > an additional discussion on the impact of PITR that is out of the > scope of the document.}} > > PITRs (proxy ITRs) serve as ITRs for traffic from legacy hosts to > nodes in LISP sites. PETRs (proxy ETRs) serve as ETRs for LISP > traffic to legacy host. > > Note that return traffic to a legacy host from a LISP-using node does > not necessarily have to pass through an ITR/PETR pair - the original > packets can usually just be sent directly to the ultimate > destination. However, for some kinds of LISP operation (e.g. mobile > nodes), this is not possible; in these situations, the PETR is > needed. > > 15.2.1.1. PITRs > > To serve as ITRs for traffic from legacy hosts to nodes in LISP > sites, PITRs they have to advertise into the existing legacy backbone > Internet routing the availability of whatever ranges of EIDs (i.e. of > nodes using LISP) they are proxying for, so that legacy hosts will > know where to send traffic to those LISP nodes. PITR implies that > EID prefixes are advertised in BGP. > > This technique may have an impact on routing table in the Internet > core, but it is not clear yet exactly what that impact will be; it is > very dependent on the collected details of many individual deployment > decisions. > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 40] > > Internet-Draft LISP Introduction July 2014 > > > A PITR may cover a group of EID blocks with a single EID > advertisement to the core, in order to reduce the number of routing > table entries added. In fact, at the moment, aggressive aggregation > of EID announcements is performed, precisely to to minimize the > number of new announced routes added by this technique. > > At the same time, if a site does traffic engineering with LISP > instead of fine-grained BGP announcement, that will help keep table > sizes down (and this is true even in the early stages of LISP > deployment). The same is true for multi-homing. {{Maybe mixing two > concepts? LISP TE tools will still apply to traffic between PITR and > LISP site.}} > > As mentioned previously (Section 12.1), an ITR at another LISP site > can avoid using a PITR (i.e. it can detect that a given ultimate > destination is not a legacy host, if a PITR is advertising it into > the Internet core) by checking to see if a LISP mapping exists for > that ultimate destination. > > 15.2.1.2. PETRs > > PETRs (proxy ETRs) serve as ETRs for LISP traffic to legacy hosts, > for cases where a LISP node cannot send packets to such hosts without > encapsulation. That typically happens for one of two reasons. > > First, it will happen in places where some device is implementing > Unicast Reverse Path Forwarding (uRPF), to prevent a variety of > negative behaviour; originating packets with the original source's > EID in the source address field will result in them being filtered > out and discarded. > > {{Suggestion by editors: would adding and example be useful?}} > > Second, it will happen when a LISP site wishes to send packets to a > non-LISP site, and the path in between does not support the > particular IP protocol version used by the original source along its > entire length. Use of a PETR on the other side of the gap will allow > the LISP site's packet to 'hop over' the gap, by utilizing LISP's > built-in support for mixed protocol encapsulation. > > PETRs are generally used by specific ITRs, which have the location of > their PETRs configured into them. In other words, unlike normal > ETRs, PETRs do not have to register themselves in the mapping > database, on behalf of any legacy sites they serve. > > Also, allowing an ITR to always send traffic leaving a site to a PETR > does avoid having to chose whether or not to encapsulate packets; it > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 41] > > Internet-Draft LISP Introduction July 2014 > > > can just always encapsulate packets, sending them to the PETR if it > has no specific mapping for the ultimate destination. > > 15.2.2. LISP-NAT > > {{Suggestion by editors: Remove this section, LISP-NAT is not a WG > document neither an inter-networking mechanisms.}} > > A LISP-NAT router, as previously mentioned, combines LISP and NAT > functionality, in order to allow a LISP site which is internally > using addresses which cannot be globally routed to communicate with > non-LISP sites elsewhere in the Internet. (In other words, the > technique used by the PITR approach simply cannot be used in this > case.) > > To do this, a LISP-NAT performs the usual NAT functionality, and > translates a host's source address(es) in packets passing through it > from an inner value to an outer value, and storing that translation > in a table, which it can use to similarly process subsequent packets > (both outgoing and incoming). [RFC6832] > > {{Suggestion by editors: remove the following paragraph, does not > bring anything}} > > There are two main cases where this might apply: > > o Sites using non-routable global addresses > > o Sites using private addresses [RFC1918] > > 15.3. Use Through NAT Devices > > {{Suggestion by editors: Remove this section, LISP-NAT is not a WG > document neither an inter-networking mechanisms.}} > > NATs are both ubiquitous, and here to stay for a long time to come. > [RFC1631] Thus, in the actual Internet of today, having any new > mechanisms function well in the presence of NATs (i.e. with LISP xTRs > behind a NAT device) is absolutely necessary. > > LISP has produced a variety of mechanisms to do this. An > experimental mechanism to support them had major limitations; it, and > its limitations, are described in Appendix B.5. > > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 42] > > Internet-Draft LISP Introduction July 2014 > > > 15.4. LISP and Core Internet Routing > > {{Suggestion by editors: Remove this section, this is already > explained in lisp-deployment}} > > One of LISP's original motivations was to control the growth of the > size of routing tables in the Internet core, the part where routes to > all destinations must be available. As LISP becomes more widely > deployed, it can help with this issue, in a variety of ways. > > In covering this topic, one must recognize that conditions in various > stages of LISP deployment (in terms of ubiquity) will have a large > influence. [RFC7215] introduced useful terminology for this > progression, in addition to some coverage of the topic (see > Section 5, "Migration to LISP"): > > The loosely defined terms of early transition phase, late transition > phase, and LISP Internet phase refer to time periods when LISP sites > are a minority, a majority, or represent all edge networks > respectively. > > In the early phases of deployment, two primary effects will allow > LISP to have a positive impact on the routing table growth: > > o Using LISP for traffic engineering instead of BGP > > o Aggregation of smaller PI sites into a single PITR advertisement > > The first is fairly obvious (doing TE with BGP requires injecting > more-specific routes into the Internet core routing tables, something > doing TE with LISP avoids); the second is not guaranteed to happen > (since it requires coordination among a number of different parties), > and only time will tell if it does happen. > > 16. Fault Discovery/Handling > > {{Suggestion by editors: Remove this section, although this section > helps understanding how many of the LISP mechanisms work > (particularly the ones described in section 12) it provides an > unnecessary level of (operational) detail. This level of > understanding should be achieved reading the main LISP spec. }} > > The structure of LISP gives rise to a moderate number of of failure > modes. > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 43] > > Internet-Draft LISP Introduction July 2014 > > > 16.1. Handling Missing Mappings > > To handling missing mappings, the ITR calls for the mapping, and in > the meantime can either discard traffic to that ultimate destination > (as many ARP implementations do) [RFC0826], or, if dropping the > traffic is deemed undesirable, it can forward them via a PITR. > > 16.2. Outdated Mappings > > If a mapping changes once an ITR has retrieved it, that may result in > traffic to the EIDs covered by that mapping failing. There are three > cases to consider: > > o When the ETR to which traffic is being sent is still a valid ETR > for that EID, but the mapping has been updated (e.g. to change the > priority of various ETRs) > > o When the ETR traffic is being sent to is still an ETR, but no > longer a valid ETR for that EID > > o When the ETR traffic is being sent to is no longer an ETR > > 16.2.1. Outdated Mappings - Updated Mapping > > A 'mapping versioning' system, whereby mappings have version numbers, > and ITRs are notified when their mapping is out of date, has been > added to detect this, and the ITR responds by refreshing the mapping. > [RFC6834] > > 16.2.2. Outdated Mappings - Wrong ETR > > 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. > > It might be argued that if the ETR is properly managing the lifetimes > on its mapping entries, this cannot happen, but it is a wise design > methodology to assume that cannot happen events will in fact happen > (as they do, due to software errors, or, on rare occasions, hardware > faults), and ensure that the system will handle them properly. > > ETRs can easily detect cases where this happens, after they have un- > wrapped a user data packet; in response, they send a Solicit-Map- > Request to the source ITR to cause it to refresh its mapping. > > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 44] > > Internet-Draft LISP Introduction July 2014 > > > 16.2.3. Outdated Mappings - No Longer an ETR > > In another case for what can happen if an ITR uses an outdated > mapping, the destination of traffic from an ITR might no longer be a > LISP node at all. In such cases, one might get an ICMP Destination > Unreachable (Port Unreachble subtype) error message. However, one > cannot depend on that - and in any event, that would provide an > attack vector, so it should be used with care. (See [RFC6830], > Section 6.3 for more about this.) > > The following mechanism will work, though. Since the destination is > not an ETR, the echoing reachability detection mechanism (see > Section 12.3.2, "Echo Nonces") will detect a problem. At that point, > the backstop mechanism, Probing, will kick in. Since the destination > is still not an ETR, that will fail, too. > > At that point, traffic will be switched to a different ETR, or, if > none are available, a reload of the mapping may be initiated. > > 16.3. Erroneous Mappings > > {{Suggestion by editors: this section brings nothing, remove it}} > > 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. > > 16.4. Verifying ETR Liveness > > The ITR, like all packet switches, needs to detect, and react, when > its neighbour ceases operation. As LISP traffic is effectively > always uni-directional (from ITR to ETR), this could be somewhat > problematic. > > Solving a related problem, "neighbour ETR" "reachability" below) > subsumes handling this fault mode, however. > > {{Suggestion by editors: remove next paragraph }} > > Note that the two terms - liveness and reachability - are not > synonymous (although they are often confused). Liveness is a > property of a node - it is either up and functioning, or it is not. > Reachability is only a property of a particular pair of nodes. > > If packets sent from a first node to a second are successfully > received at the second, it is reachable from the first. However, the > second node may at the very same time not be reachable from some > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 45] > > Internet-Draft LISP Introduction July 2014 > > > other node. Reachability is always a ordered pairwise property, and > of a specified ordered pair. > > 16.5. Verifying ETR Reachability > > A more significant issue than whether a particular ETR is up or not > is, as mentioned above, that although the ETR may be up, attached to > the network, etc, an issue in the network, between a source ITR, and > the ETR, may prevent traffic from the ITR from getting to the ETR. > (Perhaps a routing problem, or perhaps some sort of access control > setting.) > > The one-way nature of LISP traffic makes this situation hard to > detect with simple and non-intrusive techniques. In line with the > LISP design philosophy this problem is then attacked not with a > single mechanism (which would be complex) but with a collection of > simple mechanisms. > > They are reliance on the underlying routing system (which can of > course only reliably provide a negative reachabilty indication, not a > positive one), the echo nonce (which depends on some return traffic > from the destination xTR back to the source xTR), and finally RLOC > probing, in the case where no positive echo is returned. > > {{Suggestion by editors: remove next paragraph }} > > (The last is not the first choice, as due to the large fan-out > expected of LISP router, reliance on it as a sole mechanism would > produce a fair amount of overhead.) > > 17. Acknowledgments > > This document was initiated by Noel Chiappa, and much of the core > philosophy came from him. We acknowledge the important contributions > he has made to this work and thank him for his past efforts. > > The author would like to start by thanking all the members of the > core LISP group for their willingness to allow him to add himself to > their effort, and for their enthusiasm for whatever assistance he has > been able to provide. > > He would also like to thank (in alphabetical order) Michiel Blokzijl, > Peter Chiappa, Vina Ermagan, Dino Farinacci, Vince Fuller and > Vasileios Lakafosis for their review of, and helpful suggestions for, > this document. (If I have missed anyone in this list, I apologize > most profusely.) > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 46] > > Internet-Draft LISP Introduction July 2014 > > > A special thank you goes to Joel Halpern, who almost invariably, when > asked, promptly returned comments on intermediate versions of this > document. Grateful thanks go also to Darrel Lewis for his help with > material on non-Internet uses of LISP, and to Dino Farinacci and > Vince Fuller for answering detailed questions about some obscure LISP > topics. > > A final thanks is due to John Wrocklawski for the author's > organizational affiliation, and to Vince Fuller for help with XML. > This memo was created using the xml2rfc tool. > > I would like to dedicate this document to the memory of my parents, > who gave me so much, and whom I can no longer thank in person, as I > would have so much liked to be able to. > > 18. IANA Considerations > > This document makes no request of the IANA. > > 19. Security Considerations > > This memo does not define any protocol and therefore creates no new > security issues. > > 20. References > > 20.1. Normative References > > [AFI] IANA, , "Address Family Indicators (AFIs)", > http://www.iana.org/assignments/address-family-numbers , > January 2011. > > [I-D.ermagan-lisp-nat-traversal] > Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, > F., and C. White, "NAT traversal for LISP", draft-ermagan- > lisp-nat-traversal-05 (work in progress), February 2014. > > [I-D.farinacci-lisp-te] > Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic > Engineering Use-Cases", draft-farinacci-lisp-te-06 (work > in progress), March 2014. > > [I-D.ietf-lisp-ddt] > Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP > Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in > progress), March 2013. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 47] > > Internet-Draft LISP Introduction July 2014 > > > [I-D.ietf-lisp-lcaf] > Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical > Address Format (LCAF)", draft-ietf-lisp-lcaf-05 (work in > progress), May 2014. > > [I-D.ietf-lisp-perspective] > Chiappa, J., "An Architectural Perspective on the LISP > Location-Identity Separation System", draft-ietf-lisp- > perspective-00 (work in progress), February 2013. > > [I-D.ietf-lisp-sec] > Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. > Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 > (work in progress), April 2014. > > [I-D.ietf-lisp-threats] > Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats > Analysis", draft-ietf-lisp-threats-10 (work in progress), > July 2014. > > [I-D.meyer-lisp-mn] > Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP > Mobile Node", draft-meyer-lisp-mn-10 (work in progress), > January 2014. > > [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, > August 1980. > > [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September > 1981. > > [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 > (IPv6) Specification", RFC 2460, December 1998. > > [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. > > [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, > "Interworking between Locator/ID Separation Protocol > (LISP) and Non-LISP Sites", RFC 6832, January 2013. > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 48] > > Internet-Draft LISP Introduction July 2014 > > > [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation > Protocol (LISP) Map-Server Interface", RFC 6833, January > 2013. > > [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID > Separation Protocol (LISP) Map-Versioning", RFC 6834, > January 2013. > > [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- > Pascual, J., and D. Lewis, "Locator/Identifier Separation > Protocol (LISP) Network Element Deployment > Considerations", RFC 7215, April 2014. > > 20.2. Informative References > > [Atkinson] > R. Atkinson, , "Revised draft proposed definitions", RRG > list message, Message-Id: 808E6500-97B4-4107- 8A2F- > 36BC913BE196@extremenetworks.com, 11 June 2007, > http://www.ietf.org/mail-archive/web/ram/current/ > msg01470.html , . > > [Baran] P. Baran, , "On Distributed Communications Networks", IEEE > Transactions on Communications Systems Vol. CS-12 No. 1, > pp. 1-9 , March 1964. > > [Bibliography] > J.N. Chiappa, , "LISP (Location/Identity Separation > Protocol) Bibliography", > http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html , > July 2013. > > [Chiappa] J.N. Chiappa, , "Endpoints and Endpoint Names: A Proposed > Enhancement to the Internet Architecture", Personal draft > (work in progress), 1999, > http://www.chiappa.net/~jnc/tech/endpoints.txt , 1999. > > [Clark] D. D. Clark, , "The Design Philosophy of the DARPA > Internet Protocols", Proceedings of the Symposium on > Communications Architectures and Protocols SIGCOMM '88', > pp. 106-114 , 1988. > > [CorasBGP] > F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, and > J. Domingo-Pascual, , "Implementing a BGP-free ISP Core > with LISP", Proceedings of the Global Communications > Conference (GlobeCom), IEEE, pp. 2772-2778 , December > 2012. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 49] > > Internet-Draft LISP Introduction July 2014 > > > [CorasCache] > J. Kim, L. Iannone, and A. Feldmann, , "On the Cost of > Caching Locator/ID Mappings", Proceedings of the 10th > International IFIP TC 6 Conference on Networking - Volume > Part I (NETWORKING '11)', IFIP, pp. 367-378 , May 2011. > > [Future] J.N. Chiappa, , "Potential Long-Term Developments With the > LISP System", draft-chiappa-lisp-evolution-00 (work in > progress) (NOT EXISTING) , October 2012. > > [Heart] F. E. Heart, R. E. Kahn, S. M. Ornstein, W. R. Crowther, > and D. C. Walden, , "The Interface Message Processor for > the ARPA Computer Network", Proceedings AFIPS SJCC, Vol. > 36, pp. 551-567 , 1970. > > [I-D.farinacci-lisp] > Farinacci, D., "Locator/ID Separation Protocol (LISP)", > draft-farinacci-lisp-00 (work in progress), January 2007. > > [IEN19] J. F. Shoch, , "Inter-Network Naming, Addressing, and > Routing", IEN (Internet Experiment Note) 19 , January > 1978. > > [Iannone] L. Iannone and O. Bonaventure, , "On the Cost of Caching > Locator/ID Mappings", Proceedings of the 3rd International > Conference on emerging Networking EXperiments and > Technologies (CoNEXT'07)', ACM, pp. 1-12 , December 2007. > > [Improvements] > J.N. Chiappa, , "An Overview of On-Going Improvements to > the LISP Location-Identity Separation System", draft- > chiappa-lisp-improvements-00 (work in progress) (NOT > EXISTING) , September 2013. > > [Kim] L. Iannone and O. Bonaventure, , "A Deep Dive Into the > LISP Cache and What ISPs Should Know About It", > Proceedings of the 3rd International Conference on > emerging Networking EXperiments and Technologies > (CoNEXT'07)', ACM, pp. 1-12 , December 2007. > > [LISP-TREE] > L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, and > O. Bonaventure, , "LISP-TREE: A DNS Hierarchy to Support > the LISP Mapping System", IEEE Journal on Selected Areas > in Communications', Vol. 28, No. 8, pp. 1332-1343 , > October 2010. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 50] > > Internet-Draft LISP Introduction July 2014 > > > [NIC8246] A. McKenzie and J. Postel, , "Host-to-Host Protocol for > the ARPANET", NIC 8246, Network Information Center, SRI > International, Menlo Park, CA , October 1977. > > [NSAP] International Organization for Standardization, , > "Information Processing Systems - Open Systems > Interconnection - Basic Reference Model", ISO Standard > 7489.1984 , 1984. > > [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or > converting network protocol addresses to 48.bit Ethernet > address for transmission on Ethernet hardware", STD 37, > RFC 826, November 1982. > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, November 1987. > > [RFC1498] Saltzer, J., "On the Naming and Binding of Network > Destinations", RFC 1498, August 1993. > > [RFC1631] Egevang, K. and P. Francis, "The IP Network Address > Translator (NAT)", RFC 1631, May 1994. > > [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC > 1812, June 1995. > > [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and > E. Lear, "Address Allocation for Private Internets", BCP > 5, RFC 1918, February 1996. > > [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The > Nimrod Routing Architecture", RFC 1992, August 1996. > > [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition > of Explicit Congestion Notification (ECN) to IP", RFC > 3168, September 2001. > > [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: > Challenges and Solutions", RFC 3170, September 2001. > > [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. > Xiao, "Overview and Principles of Internet Traffic > Engineering", RFC 3272, May 2002. > > [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual > Private Network (VPN) Terminology", RFC 4026, March 2005. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 51] > > Internet-Draft LISP Introduction July 2014 > > > [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. > Rose, "DNS Security Introduction and Requirements", RFC > 4033, March 2005. > > [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic > Key Management", BCP 107, RFC 4107, June 2005. > > [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. > Gill, "IPv4 Multihoming Practices and Limitations", RFC > 4116, July 2005. > > [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast > Services", BCP 126, RFC 4786, December 2006. > > [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB > Workshop on Routing and Addressing", RFC 4984, September > 2007. > > [RFC5110] Savola, P., "Overview of the Internet Multicast Routing > Architecture", RFC 5110, January 2008. > > [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering > Still Needs Work", RFC 5887, May 2010. > > [RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC > 6115, February 2011. > > [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, > "Locator/ID Separation Protocol Alternative Logical > Topology (LISP+ALT)", RFC 6836, January 2013. > > [Saltzer] J. H. Saltzer, D. P. Reed, and D. D. Clark, , "End-To-End > Arguments in System Design", ACM TOCS, Vol 2, No. 4, pp > 277-288 , November 1984. > > [Saucez] D. Saucez, L. Iannone, and B. Donnet, , "A First > Measurement Look at the Deployment and Evolution of the > Locator/ID Separation Protocol", ACM SIGCOMM Computer > Communication Review', Vol. 43 No. 2, pp. 37-43 , April > 2013. > > Appendix A. Glossary/Definition of Terms > > {{Suggestion by editors: remove and use those from RFCs instead }} > > o EID, Enpoint Identifier: Originally defined as a name for an > endpoint, one with purely identity semantics, and globally unique, > and with syntax of relatively short fixed length. It is used in > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 52] > > Internet-Draft LISP Introduction July 2014 > > > the LISP work to mean the identifier of a node; it is the input to > an EID->RLOC lookup in the mapping system; it is usually an IP > address. The source and destination addresses of the innermost > header in a LISP packet are usually EIDs. > > o RLOC, Routing Locator: a LISP-specific term meaning the locator > associated with an entity identified by an EID; as such, it is > often the output of an EID->RLOC lookup in the mapping system; it > is usually an IP address, and of an ETR. The source and > destination addresses of the outermost header in a LISP packet are > usually RLOCs. > > o ITR, Ingress Tunnel Router: a LISP router at the border of a LISP > site which takes user packets sent to it from inside the LISP > site, encapsulates in a LISP header, and then sends them across > the Internet to an ETR; in other words, the start of a tunnel from > the ITR to an ETR. > > o ETR: Egress Tunnel Router: a LISP router at the border of a LISP > site which decapsulates user packets which arrive at it > encapsulated in a LISP header, and sends them on towards their > ultimate destination; in other words, the end of the tunnel from > an ITR to the ETR. > > o Neighbour ETR: Although an ITR and ETR may be separated by many > actual physical hops, at the LISP level, they are direct > neighbours; so any ETR which an ITR sends traffic to is a > neighbour ETR of that ITR. > > o xTR: An xTR refers to a LISP router which functions both as an ITR > and an ETR (which is typical), when the discussion involves packet > flows in both directions through the router, which results in it > alternately functioning as an ITR and then as an ETR. > > o Reachable; Reachability; Neighbour ETR Reachability: The ability > of an ITR to be able to send packets to a neighbour ETR, or the > property of an ITR to be able to send such packets. > > o Liveness: Whether a LISP node of any kind is up and operating, or > not; or the property of a LISP node to be in such a state. > > o MR, Map Resolver: A LISP node to which ITRs send requests for > mappings. > > o MS, Map Server: A LISP node with which ETRs register mappings, to > indicate their availability to handle incoming traffic to the EIDs > covered in those mappings. > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 53] > > Internet-Draft LISP Introduction July 2014 > > > o Mapping System: The entire ensemble of data and mechanisms which > allow clients - usually ITRs - to find mappings (from EIDs to > RLOCs). It includes both the mapping database, and also > everything used to gain access to it - the MRs, the indexing sub- > system, etc. > > o Mapping Database: The term mapping database refers to the entire > collection of EID-to-RLOC mappings spread throughout the entire > LISP system. It is a subset of the mapping system. > > o Mapping Cache: A collection of copies of EID-to-RLOC mappings > retained in an ITR; not the entire mapping database, but just the > subset of it that an ITR needs in order to be able to properly > handle the user data traffic which is flowing through it. > > o Indexing Sub-system: the entire ensemble of data and mechanisms > which allows MRs to find out which ETR(s) hold the mapping for a > given EID or EID block. It includes both the data on namespace > delegations, as well as the nodes which hold that data, and the > protocols used to interact with those nodes. > > o DDT Vertex; Vertex: a node (in the graph theory sense of the term) > in the (abstract) LISP namespace delegation hierarchy. > > o DDT Server: an actual machine, which one can send packets to, in > the DDT server hierarchy - which is, hopefully, a one-to-one > projection of the LISP address delegation hierarchy (although of > course a single DDT vertex may turn into several sibling servers). > Some documents refer to these as DDT nodes but this document does > not use that term, to prevent confusion with DDT vertex. > > o PITR: Proxy ITR; an ITR which is used for interworking between a > LISP-speaking node or site, and legacy nodes or sites; in general, > it acts like a normal ITR, but does so on behalf of LISP nodes > which are receiving packets from a legacy node. > > o PETR: Proxy ETR; an ETR which is used for interworking between a > LISP-speaking node or site, and legacy nodes or sites; in general, > it acts like a normal ETR, but does so on behalf of LISP nodes > which are sending packets to a legacy node. > > o RTR: Re-encapsulating Tunnel Router; a data plane 'anchor point' > used by a LISP-speaking node to perform functions that can only be > be performed in the core of the network. One use is for LISP- > speaking node behind a NAT device to send and receive traffic > through the NAT device; see > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 54] > > Internet-Draft LISP Introduction July 2014 > > > o Internet core: That part of the Internet in which there are no > 'default' entries in routing tables, but where the routing tables > hold entries for every single reachable destination in the > Internet. (Sometimes referred to colloquially as the DFZ, or > 'Default Free Zone'.) > > Appendix B. Other Appendices > > B.1. A Brief History of Location/Identity Separation > > It was only gradually realized in the networking community that > networks (especially large networks) should deal quite separately > with the identity and location of a node; the distinction between the > two was more than a little hazy at first. > > The ARPANET had no real acknowledgment of the difference between the > two. [Heart][NIC8246] The early Internet also co-mingled the two > ([RFC0791]), although there was recognition in the early Internet > work that there were two different things going on. [IEN19] > > This likely resulted not just from lack of insight, but also the fact > that extra mechanism is needed to support this separation (and in the > early days there were no resources to spare), as well as the lack of > need for it in the smaller networks of the time. (It is a truism of > system design that small systems can get away with doing two things > with one mechanism, in a way that usually will not work when the > system gets much larger.) > > The ISO protocol architecture took steps in this direction [NSAP], > but to the Internet community the necessity of a clear separation was > definitively shown by Saltzer. [RFC1498] Later work expanded on > Saltzer's, and tied his separation concepts into the fate-sharing > concepts of Clark. [Clark], [Chiappa] > > The separation of location and identity is a step which has recently > been identified by the IRTF as a critically necessary evolutionary > architectural step for the Internet. [RFC6115] However, it has taken > quite some time for this requirement to be generally accepted by the > Internet engineering community at large, although it seems that this > may finally be happening. > > Unfortunately, although the development of IPv6 presented a golden > opportunity to learn from this particular failing of IPv4, that > design failed to recognize the need for separation of location and > identity. > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 55] > > Internet-Draft LISP Introduction July 2014 > > > B.2. A Brief History of the LISP Project > > {{Suggestion by editors: remove that makes no sense in this document > }} > > The LISP system for separation of location and identity resulted from > the discussions of this topic at the Amsterdam IAB Routing and > Addressing Workshop, which took place in October 2006. [RFC4984] > > A small group of like-minded personnel from various scattered > locations within Cisco, spontaneously formed immediately after that > workshop, to work on an idea that came out of informal discussions at > the workshop. The first Internet-Draft on LISP appeared in January, > 2007, along with a LISP mailing list at the IETF. > [I-D.farinacci-lisp] > > Trial implementations started at that time, with initial trial > deployments underway since June 2007; the results of early experience > have been fed back into the design in a continuous, ongoing process > over several years. LISP at this point represents a moderately > mature system, having undergone a long organic series of changes and > updates. > > LISP transitioned from an IRTF activity to an IETF WG in March 2009, > and after numerous revisions, the basic specifications moved to > becoming RFCs at the start of 2013 (although work to expand and > improve it, and find new uses for it, continues, and undoubtly will > for a long time to come). > > B.3. Old LISP 'Models' > > LISP, as initilly conceived, had a number of potential operating > modes, named 'models'. Although they are now obsolete, one > occasionally sees mention of them, so they are briefly described > here. > > o LISP 1: EIDs all appear in the normal routing and forwarding > tables of the network (i.e. they are 'routable');this property is > used to 'bootstrap' operation, by using this to load EID->RLOC > mappings. Packets were sent with the EID as the destination in > the outer wrapper; when an ETR saw such a packet, it would send a > Map-Reply to the source ITR, giving the full mapping. > > o LISP 1.5: Similar to LISP 1, but the routability of EIDs happens > on a separate network. > > o LISP 2: EIDs are not routable; EID->RLOC mappings are available > from the DNS. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 56] > > Internet-Draft LISP Introduction July 2014 > > > o LISP 3: EIDs are not routable; and have to be looked up in in a > new EID->RLOC mapping database (in the initial concept, a system > using Distributed Hash Tables). Two variants were possible: a > 'push' system, in which all mappings were distributed to all ITRs, > and a 'pull' system in which ITRs load the mappings they need, as > needed. > > B.4. The ALT Mapping Indexing Sub-system > > LISP initially used an indexing sub-system called ALT. [RFC6836]ALT > re-purposed a number of existing mechanisms to provide an indexing > system, which allowed an experimental LISP initial deployment to > become operational without having to write a lot of code, ALT was > relatively easily constructed from basically unmodified existing > mechanisms; it used BGP running over virtual tunnels using GRE. > > ALT proved to have a number of issues which made it unsuitable for > large-scale use, and it has now been superseded by DDT. A complete > list of these is not possible here, but the issues mostly were of two > kinds: technical issues which would have arisen at large scale, and > practical operational issues which appeared even in the experimental > deployment. > > The biggest operational issues was the effort involved in > configuring, and maintain the configuration, of the virtual tunnels > over which ALT ran (including assigning the addresses for the ends, > etc); also, managing the multiple disjoint routing tables required > was difficult and confusing (even for those who were very familiar > with ALT). Debugging faults in ALT was also difficult; and finally, > because of ALT's nature, administrative issues (who pays for what, > who controls what, etc) were problematic. > > However, ALT would have had significant technical issues had it been > used at a larger scale. > > The most severe (and fundamental) issue was that since all traffic on > the ALT had to transit the 'root' of the ALT tree, those locations > would have become traffic 'hot-spots' in a large scale deployment. > > In addition, optimal performance would have required that the ALT > overall topology be restrained to follow the EID namespace > allocation; however, it was not clear that this was feasible. In any > event, even optimal performance was still less than that in > alternatives. The ALT was also very vulnerable to misconfiguration. > > See [LISP-TREE] for more about these issues: the basic structure and > operation of DDT is identical to that of TREE, so the conclusions > drawn there about TREE's superiority to ALT apply equally to DDT. > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 57] > > Internet-Draft LISP Introduction July 2014 > > > In particular, the big advantage of DDT over the ALT, in performance > terms, is that it allows MRs to interact _directly_ with distant DDT > servers (as opposed to the ALT, which _always_ required mediation > through intermediate servers); caching of information about those > distant servers allows DDT to make extremely effective use of this > capability. > > The ALT did have some useful properties which its replacement, DDT, > did not, e.g. the ability to forward data directly to the > destination, over the ALT, when no mapping was available yet for the > destination. However, these were minor, and heavily outweighed by > its problems. > > A recent study, [Saucez], measured actual resolution times in the > deployed LISP network during the changeover from ALT to DDT, allowing > direct comparison of the performance of the two systems. The study > took measurements from a variety of locations in the Internet, with > respect to a number of different target EIDs. The results indicate > that the performance was almost identical; there was more variance > with DDT (perhaps due to the effects of caching), but the greatly > improved scalability of DDT as compared to ALT made that effect > acceptable. > > B.5. Early NAT Support > > The first mechanism used by LISP to support operation through a NAT > device, described here, has now been superseded by the more general > mechanism proposed in [I-D.ermagan-lisp-nat-traversal]. That > mechanism is, however, based heavily on this mechanism. The initial > mechanism had some serious limitations, which is why that particular > form of it has been dropped. > > First, it only worked with some NATs, those which were configurable > to allow inbound packet traffic to reach a configured host. The NAT > had to be configured to know of the ETR. > > Second, since NATs share addresses by using ports, it was only > possible to have a single LISP node behind any given NAT device. > That is because LISP expects all incoming data traffic to be on a > specific port, so it was not possible to have multiple ETRs behind a > single NAT (which normally would have only one global IP address to > share). Even looking at the sort host and port would not necessarily > help, because some source ITR could be sending packets to both ETRs, > so packets to either ETR could also have the identical source host/ > port. In short, there was no way for a NAT with multiple ETRs behind > it to know which ETR the packet was for. > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 58] > > Internet-Draft LISP Introduction July 2014 > > > To support operation behind a NAT, there was a pair of new LISP > control messages, LISP Echo-Request and Echo-Reply, which allowed the > ETR to discover its temporary global address. The Echo-Request was > sent to the configured Map-Server, and it replied with an Echo-Reply > which included the source address from which the Echo Request was > received (i.e. the public global address assigned to the ETR by the > NAT). The ETR could then insert that address in any Map-Reply > control messages which it sent to correspondent ITRs. > > Echo-Request and Echo-Reply have been replaced by Info-Request and > Info-Reply in the replacement, [NAT-Traversal], where they perform > very similar functions; the main change is the addition of the {{xxx > - probably the port, etc to allow multiple XTRs behind a NAT}}. > > Authors' Addresses > > Albert Cabellos-Aparicio (Ed.) > Technical University of Catalonia > C/Jordi Girona, s/n > BARCELONA 08034 > Spain > > Email:jacabello@ac.upc.edu > > > Damien Saucez (Ed.) > INRIA > 2004 route des Lucioles BP 93 > 06902 Sophia Antipolis Cedex > France > > Email:damien.saucez@inria.fr > > > > > > > > > > > > > > > > > > > > Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 59] From nobody Sat Jul 26 00:45:24 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B5B1A037F for ; Sat, 26 Jul 2014 00:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMFOFf3mW5nc for ; Sat, 26 Jul 2014 00:45:17 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F14C1A037E for ; Sat, 26 Jul 2014 00:45:16 -0700 (PDT) Received: (qmail 32743 invoked from network); 26 Jul 2014 07:44:45 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 26 Jul 2014 07:44:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 26 Jul 2014 09:44:43 +0200 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: <53D2BC3B.1090308@cisco.com> References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> <53EE128C-1552-4F00-AECF-6EE8511A4D18@gigix.net> <53D2BC3B.1090308@cisco.com> Message-ID: <7765c0743c6465c3fb90a0f1c5aea982@triangulum.uberspace.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/UPn7XdEY7O3ynJ0JVjMXblSNrwM Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 07:45:20 -0000 Am 2014-07-25 22:21, schrieb Fabio Maino: >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page >> 12] >> >> Internet-Draft LISP Introduction July >> 2014 >> >> >> 7. Initial Applications >> >> {{Suggested by editors: Move this section after section 8, the >> applications should not be described before LISP has been fully >> described. >> >> {{Suggested by Noel: Reorder the whole section in popularity >> order?}} >> >> As previously mentioned, it is felt that LISP will provide even >> the >> earliest adopters with some useful capabilities, and that these >> capabilities will drive early LISP deployment. >> >> It is very imporant to note that even when used only for >> interoperation with existing un-modified hosts, use of LISP can >> still >> provide benefits to the site which has deployed it - and, perhaps >> even more importantly, can do so to both sides. This >> characteristic >> acts to further enhance the utility for early adopters of LISP. >> >> Note also that this section only lists some early applications and >> benefits. See [I-D.ietf-lisp-perspective], in the Section "Goals >> of >> LISP", for a more extensive discussion of some of what LISP might >> ultimately provide. >> >> 7.1. Provider Independence >> >> Provider independence (i.e. the ability to easily change one's >> Internet Service Provider) is a good example of the utility of >> separating location and identity. >> >> To limit global routing table size addresses need to be >> aggregated. >> To that aim networks can use provider aggregatable addresses >> ([RFC4116]) which means that the IP prefixes of networks are sub- >> prefixes of their provider. This solutions allows to reduce >> scalability issues of the global routing table but it means that >> when >> a network switches providers it has to re-number all its devices >> which is known to be complex in current networks [RFC5887]. >> >> Having separate namespaces for location and identity greatly >> reduces >> the problems involved with re-numbering; an organization which >> moves >> retains its EIDs (which are how most other parties refer to its >> nodes), but is allocated new RLOCs, and the mapping system can >> quickly provide the updated mapping from the EIDs to the new >> RLOCs. >> >> 7.2. Multi-Homing >> >> {{Suggested by editors: This section should be extended, it is >> unclear the benefits that LISP brings to multihoming (.e.g, >> traffic >> engineering, decoupled multihoming from the data-plane). >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page >> 13] >> >> Internet-Draft LISP Introduction July >> 2014 >> >> >> Multi-homing is another place where the value of separation of >> location and identity became apparent. There are several >> different >> sub-flavours of the multi-homing problem - e.g. depending on >> whether >> one wants open TCP connections to keep working, etc - and other >> axes >> as well (e.g. site multi-homing versus host multi-homing). >> >> In particular, for the 'keep open connections up' case, without >> separation of location and identity, with most currently deployed >> implementations, the only currently feasible approach is to use >> provider-independent addressses - which moves the problem into the >> global routing system, with attendant costs. This approach is >> also >> not really feasible for host multi-homing. >> >> 7.3. Traffic Engineering >> >> {{Suggestion by editors: Merge this section with the previous one, >> TE >> is not practical without multihoming}} >> >> {{Needs a fix - not sure what.}} >> >> Traffic engineering (TE) [RFC3272], desirable though this >> capability >> is in a global network, is currently somewhat problematic to >> provide >> in the Internet. The problem, fundamentally, is that this >> capability >> was not forseen when the Internet was designed, so the support for >> it >> via hacks is neither clean, nor flexible. >> >> TE is, fundamentally, a routing issue. However, the current >> Internet >> routing architecture, which is basically the Baran design of fifty >> years ago [Baran] (a single large, distributed computation), is >> ill- >> suited to provide TE. The Internet seems a long way from adopting >> a >> more-advanced routing architecture, although the basic concepts >> for >> such have been known for some time. [RFC1992] >> >> Although the identity-location mapping layer is thus a poor place, >> architecturally, to provide TE capabilities, it is still an >> improvement over the current routing tools available for this >> purpose >> (e.g. injection of more-specific routes into the global routing >> table). >> >> In addition, instead of the entire network incurring the costs >> (through the routing system overhead), when using a mapping layer >> to >> provide TE, the overhead is limited to those who are actually >> communicating with that particular destination. >> >> LISP includes a number of features in the mapping system to >> support >> TE. (described in Section 8.2, "Control Plane - Mapping System >> Overview", below); more details about using LISP for TE can be >> found >> in [I-D.farinacci-lisp-te]. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page >> 14] >> >> Internet-Draft LISP Introduction July >> 2014 >> >> >> Also, a number of academic papers have explored how LISP can be >> used >> to do TE, and how effective it can be. See the online LISP >> Bibliography ([Bibliography]) for information about them. >> >> 7.4. Routing >> >> {{Suggestion by editors: Remove this section, LISP is not a >> routing >> protocol.}} >> >> Multi-homing and Traffic Engineering are both, in some sense, uses >> of >> LISP for routing, but there are many other routing-related uses >> for >> LISP. >> >> One of the major original motivations for the separation of >> location >> and identity in general, and thus LISP, was to reduce the growth >> of >> the routing tables in the "Internet core", the part where routes >> to >> _all_ ultimate destinations must be available. LISP is expected >> to >> help with this; for more detail, see Section 15.4, "LISP and Core >> Internet Routing", below. >> >> LISP may also have more local applications in which it can help >> with >> routing; see, for instance, [CorasBGP]. >> >> 7.5. Mobility >> >> {{Suggestion by editors: Remove this section, mobility is not in >> charter.}} >> >> Mobility is yet another place where separation of location and >> identity is a key part of a clean, efficient and >> high-functionality >> solution. Considerable experimentation has been completed on >> doing >> mobility with LISP. >> >> The mobility provided by LISP allows active sessions to survive >> moves >> (provided of course that there is not a period of inaccessibility >> which exceeds a timeout). LISP mobility also will typically have >> better packet stretch (i.e. increase in path length) compared to >> traditional mobility schemes, which use a home agent. >> >> 7.6. Traversal Across Alternate IP Versions >> >> Note that LISP inherently supports intermixing of various IP >> versions >> for packet carriage; IPv4 packets might well be carried in IPv6, >> or >> vice versa, depending on the network's configuration. >> >> This capability allows an island of operation of one type to be >> automatically tunneled over a stretch of infrastucture which only >> supports the other type. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page >> 15] >> >> Internet-Draft LISP Introduction July >> 2014 >> >> >> 7.7. Virtual Private Networks >> >> {{Suggestion by editors: Remove this section, not covered by any >> WG >> document}} >> >> L2 and L3 {{Need to add text here - This used to be part of >> 'Local' >> below, but we decided this was so important it deserved its own >> section. Maybe move this up further, as it seems to be the most >> important 'early adopter' application?}} >> >> The mapping-and-encapsulation nature of LISP makes it a perfect >> candidate for VPN solutions. In this case, private parts of the >> VPN >> form LISP sites and the IP addresses of devices in the private >> parts >> are composing EID spaces. The interconnection between the LISP >> sites >> is the public network and IP addresses in the interconnection >> compose >> the RLOC space. A major advantage of using LISP to construct VPN >> resides in the simplicity of the configurations: each xTR (i.e., >> VPN >> end) is configured to query the mapping system to retrieve >> mappings >> making the glue between the public (RLOC space) and the private >> (EID >> space) of the VPN. >> >> This includes support of multi-tenancy where several private >> networks >> can be carried over the same underlayer network. Thanks to the >> instance-id field, multi-tenant network can even use the exact >> same >> addresses as the xTR distinguishes the tenant based on the value >> of >> the instance-id. The multiple address family support in LISP >> mappings also allows to build private networks using a different >> addressing family than the carrier (e.g., IPv6 over IPv4). >> >> 7.8. Local Uses >> >> {{Suggestion by editors: Remove this section. The section >> contains a >> general discussion about the applicability of LISP in intra-domain >> scenarios, however it does not describe any specific >> application.}} >> >> LISP has a number of use cases which are within purely >> organizationally-local contexts, i.e. not in the larger Internet. >> These fall into two categories: uses seen on the Internet (above), >> but here on a private (and usually small scale) setting; and >> applications which do not have a direct analog in the larger >> Internet, and which apply only to local deployments. >> >> Among the former are multi-homing and IP version traversal. {{This >> was marked to be deleted - why? The next part doesn't make sense >> without this first?}} >> >> Among the latter class, non-Internet applications which have no >> analog on the Internet, are the following example applications: >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page >> 16] >> >> Internet-Draft LISP Introduction July >> 2014 >> >> >> virtual machine mobility in data centers; non-IP EID types such as >> L2 >> MAC addresses, or application specific data. >> >> Several of the applications listed in this section are the ones >> which >> have been most popular for LISP in practise; these include virtual >> networks, and virtual machine mobility. >> >> These often show a synergistic tendency, in that a site which >> installs LISP to do one, often finds that then becomes a small >> matter >> to use it for the second. Given all the things which LISP can do, >> it >> is hoped that this synergistic effect will continue to expand >> LISP's >> uses. >> >> {{Preceeding paragraphs should probably get moved up into VPN >> section?}} >> I suggest to add LISP with carrier grade NAT as Dual-Stack Lite replacement in section 7. >> Authors' Addresses >> >> Albert Cabellos-Aparicio (Ed.) >> Technical University of Catalonia >> C/Jordi Girona, s/n >> BARCELONA 08034 >> Spain >> >> Email:jacabello@ac.upc.edu : 147.83.30.70 does not like recipient. Remote host said: 554 : Recipient address rejected: Access denied Giving up on 147.83.30.70. -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Sun Jul 27 14:21:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B8B1A01A8; Sun, 27 Jul 2014 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gai9S9KWXrAi; Sun, 27 Jul 2014 14:21:55 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5081A00D7; Sun, 27 Jul 2014 14:21:55 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so6952493qaq.1 for ; Sun, 27 Jul 2014 14:21: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=VTQUxKmJZnlk/TVANSWcZDoa0YafOxjEqyweO6/X8DE=; b=ewg/ieP1b79662qOqXfZ2j8KonHHL3wWfrtlo6EuRbfvReCkjn5S8QtGnjEIjVCjU2 nNFT/O3CLBxF05yxCO4s6G/FZZhqCXDv9C5kIAZ68ywvorKtPhP44/ml4rEqP3LC6x1j tpd77jXgW58Dl8L3v0EGLKaKN9NnuqsXGLqDFEdlP1wjzG6y4H1LDGykgfK0XujOnaA+ AVRqE3zr8yImyDCuYRpBc/iOc6oG5ogKEycMZE7b9JEGHqJH7G/+u67gy4IHu2WwI1b8 s7u1fxkwIA/eKZEAWZP8SRk8q9T6p8vxwYP8MutPK5W/FPTOWv+Wi9Ck62jl6slvRXa+ 8FpQ== X-Received: by 10.224.45.67 with SMTP id d3mr17620335qaf.11.1406496114530; Sun, 27 Jul 2014 14:21:54 -0700 (PDT) Received: from [192.168.0.10] (cblmdm72-241-167-110.buckeyecom.net. [72.241.167.110]) by mx.google.com with ESMTPSA id l76sm19950847qga.8.2014.07.27.14.21.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 14:21:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> Date: Sun, 27 Jul 2014 14:21:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> To: David Melman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/r6thI1CqoqWfE69lBjoZqu0DOqY Cc: "nvo3@ietf.org" , LISP mailing list list Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 21:21:57 -0000 > 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and = requires the assignment of a new UDP port. The fact that the VXLAN-GPE = header closely resembles VXLAN may be convenient for implementers, but = this protocol by definition is not backward compatible with VXLAN. =20 If you do that then it will be harder for VXLAN-GPE systems to = interoperate with a VXLAN systems. Because a VXLAN-GPE system will need = to open and maintain 2 UDP sockets. And an implementaiton will have to = be careful to not set the P-bit for the VXLAN socket or clear the P-bit = for VXLAN-GPE socket. This is all completely unnecessary and one way or = the other should be used. And if *it was agreed* on to use different UDP port numbers (like the = way LISP did it for L2 versus L3 packet encapsulation), we wouldn't need = the P-bit at all. But there was push back (by somebody) to not allocate = another port for VXLAN, so the demux was forced to be in the VXLAN = header.=20 And is also the reason this baggage is being carried over the LISP when = it really isn't needed. > 3. True, the =91P=92 bit is not needed for backward compatibility, but = I=92m not against it if there is value to make it consistent with the = LISP-GPE header. There is no incremental benefit to use the P-bit for LISP. We had a = solution but because of the requirement to have no new port for VXLAN, = LISP is affected. Just another example how the working group is putting effort into things = that creates more work but no benefit. Don't get me wrong, the cisco = guys did this (the VXLAN and LISP same position for P-bit) for = consistency, and they should be applauded for that. But if VXLAN could = have another port number assigned for "other protocols", maybe the = VXLAN-GPE would look so much different. Something to think about as the working group now has new productivity = mentality. Dino From nobody Sun Jul 27 17:39:19 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24BD1B27CA; Sun, 27 Jul 2014 17:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EXvKtpMJ17M; Sun, 27 Jul 2014 17:39:14 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A37B1B27C7; Sun, 27 Jul 2014 17:39:14 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id w8so7107573qac.30 for ; Sun, 27 Jul 2014 17:39:12 -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=4Zc4wsjEP52OJxm5cFCKSbazVDXmcvkuvZcg5nrFqTs=; b=V+lrqm53w9W0FC0bbp94A6SDE0NAQxESF76A5rlxhun8UpnAZQjcIhiSOkMbu1Ma+R y/zEnHDJXjGjDT/2bJUIk1cUGP4XZe0kV6wLw1/+1rj/ZRDHvSxwqEXq5VkkjTJmJh1c rgzOrMahOh0OW60JqwluJQRfTjOns9VVGl2+RrzyHGZcG9tJQI9fs65jMcgGe7/00s0T z42BAHNW+zAYr66uPrbbwykD52Gobp7kNITnINgQGCAiY+F+FJoD3G88MPF7tmwz+XMC 1tkMH0kVcdez+0tH2qdH4OyDOU/kbCXb+9hCQzCnodKfZGZ8YG4lzEiNcoqraUXLOSEW nhyA== X-Received: by 10.224.54.136 with SMTP id q8mr53008578qag.79.1406507952771; Sun, 27 Jul 2014 17:39:12 -0700 (PDT) Received: from [192.168.0.8] (cblmdm72-241-167-110.buckeyecom.net. [72.241.167.110]) by mx.google.com with ESMTPSA id u3sm26224773qas.2.2014.07.27.17.39.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 17:39:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sun, 27 Jul 2014 20:39:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> To: Tom Herbert Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/qg-3pbfMX3bBa1P4arnvTGOhnmg Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 00:39:17 -0000 I am going to let other people explain. I think my email was clear.=20 Dino > On Jul 27, 2014, at 8:28 PM, Tom Herbert wrote: >=20 > On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrot= e: >>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and req= uires the assignment of a new UDP port. The fact that the VXLAN-GPE header= closely resembles VXLAN may be convenient for implementers, but this protoc= ol by definition is not backward compatible with VXLAN. >>=20 >> If you do that then it will be harder for VXLAN-GPE systems to interopera= te with a VXLAN systems. Because a VXLAN-GPE system will need to open and ma= intain 2 UDP sockets. And an implementaiton will have to be careful to not s= et the P-bit for the VXLAN socket or clear the P-bit for VXLAN-GPE socket. T= his is all completely unnecessary and one way or the other should be used. > I am not sure what you are suggesting. AFAICT there is no backwards > compatible means to to add the protocol field to VXLAN which is the > motivation for the new UDP port, which in turn implies a new protocol > (which also implies an opportunity to add a more general set of > protocol features like version number and options extensions which are > also not backwards compatible). Maybe it's possible to break > compatibility within the protocol and assume that out of band > mechanisms could negotiate use of P-bit to compensate, but I assume > there's already quite a bit of VXLAN deployment so that seems pretty > shaky robustness-wise to me. >=20 > It's not just adding the protocol field that would be an issue, even > adding the OAM bit to VXLAN would be problematic. Per VXLAN spec > unspecified flag bits are ignored on receive, so if the OAM bit were > subsequently defined in VXLAN it will be ignored by existing > implementations and these packets will be processed normally-- this > seems to be incompatible with the proposed VXLAN-gpe requirement that > "When the O bit is set to 1, the packet is an OAM packet and OAM > processing MUST occur." (btw 'OAM processing' is awfully ambiguous to > be a MUST here IMO). >=20 > Allowing the reserved bits in the header to be ignored on receive > limits the usefulness in that new bits that are defined can only be > advisory and not fundamentally change interpretation of the packet. > Had the requirement in VXLAN been that packets with unknown bits set > be dropped, then adding P-bit and O-bit could have been done with > backwards compatibility. This might be a reasonable requirement to > consider if new protocol (i.e. new port number) is undertaken. >=20 > Thanks, > Tom >=20 >> And if *it was agreed* on to use different UDP port numbers (like the way= LISP did it for L2 versus L3 packet encapsulation), we wouldn't need the P-= bit at all. But there was push back (by somebody) to not allocate another po= rt for VXLAN, so the demux was forced to be in the VXLAN header. >>=20 >> And is also the reason this baggage is being carried over the LISP when i= t really isn't needed. >>=20 >>> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward compatib= ility, but I=E2=80=99m not against it if there is value to make it consisten= t with the LISP-GPE header. >>=20 >> There is no incremental benefit to use the P-bit for LISP. We had a solut= ion but because of the requirement to have no new port for VXLAN, LISP is af= fected. >>=20 >> Just another example how the working group is putting effort into things t= hat creates more work but no benefit. Don't get me wrong, the cisco guys did= this (the VXLAN and LISP same position for P-bit) for consistency, and they= should be applauded for that. But if VXLAN could have another port number a= ssigned for "other protocols", maybe the VXLAN-GPE would look so much differ= ent. >>=20 >> Something to think about as the working group now has new productivity me= ntality. >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From nobody Sun Jul 27 23:57:48 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452211A008C; Sun, 27 Jul 2014 23:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIb4UFHPIO_6; Sun, 27 Jul 2014 23:57:45 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8BD1A0278; Sun, 27 Jul 2014 23:57:44 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 5258A2AA0F; Mon, 28 Jul 2014 06:57:41 +0000 (GMT) Date: Sun, 27 Jul 2014 23:58:48 -0700 From: Marc Binderberger To: Tom Herbert , Dino Farinacci , David Melman Message-ID: <20140727235848276183.21b2fe35@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/ghFQhQ8OWlTgM-h9YWB7iOKvV_s Cc: "nvo3@ietf.org" , LISP mailing list list Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 06:57:47 -0000 SGVsbG8gVG9tLA0KDQpJJ20gYWxsIGZvciBwcmVjaXNlIHdvcmRpbmcgLSBidXQgb25lIHNo b3VsZG4ndCBnZXQgbG9zdCBpbiB0aGUgd29yZGluZyA6LSkNCg0KVGhlIGludGVudGlvbiBv ZiB0aGUgImNvbXBhdGliaWxpdHkiIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgc2hvdWxkIGJl IGNsZWFyLCANCmFsdGhvdWdoIHRoZSB3b3JkIGlzIGNvbmZ1c2luZzogeW91IGNhbiByZS11 c2UgeW91ciAiZ3BlIiBzZW5kL3JlY2VpdmUgbG9naWMgDQp0byBzZW5kL3JlY2VpdmUgdGhl IGV4aXN0aW5nIFZ4TEFOIGVuY2Fwcy4gQWxsIHlvdSBuZWVkIGlzIHRvIHNlbmQvcmVjZWl2 ZSBvbiANCjQ3ODkvdWRwIGluc3RlYWQgb2YgdGhlIHRvLWJlLWRlZmluZWQgZ3BlIHBvcnQg YW5kIHNldCB0aGUgZmxhZ3MvZmllbGRzIA0KYWNjb3JkaW5nbHkuDQoNClRoZSBwb2ludCBE aW5vIG1ha2VzIGlzIChJIHRoaW5rKTogaXMgdGhlcmUgcmVhbGx5IGEgZ2FpbiB0byAicmUt aW52ZW50IiANClZ4TEFOIGFuZCBMSVNQIGRhdGEgZW5jYXBzdWxhdGlvbj8gQW5kIGl0IG1p Z2h0IGJlIGFjdHVhbGx5IGVhc2llciB0byANCmltcGxlbWVudCBhbmQgdGVzdCBzZXBhcmF0 ZSBlbmNvZGluZ3MgaW5zdGVhZCBvZiB0aGUgbW9yZSBjb21wbGV4IGNvbWJpbmVkIA0KaGVh ZGVyIGluIFZ4TEFOLWdwZS4NCg0KVGhlIGNvc3Qgb2Ygbm90IGNvbWJpbmluZyBpcyBhIHBv dGVudGlhbCBhZGRpdGlvbmFsIG50aCBoZWFkZXIgZm9yIFNGQyBhbmQgDQp3aGF0ZXZlciBl bHNlIG1heSBjb21lLg0KDQoNCj4gQWxsb3dpbmcgdGhlIHJlc2VydmVkIGJpdHMgaW4gdGhl IGhlYWRlciB0byBiZSBpZ25vcmVkIG9uIHJlY2VpdmUNCj4gbGltaXRzIHRoZSB1c2VmdWxu ZXNzIGluIHRoYXQgbmV3IGJpdHMgdGhhdCBhcmUgZGVmaW5lZCBjYW4gb25seSBiZQ0KPiBh ZHZpc29yeSBhbmQgbm90IGZ1bmRhbWVudGFsbHkgY2hhbmdlIGludGVycHJldGF0aW9uIG9m IHRoZSBwYWNrZXQuDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCBpbiB0aGUgMm5k IGhhbGYgYnV0IG5vdCB5b3VyIG9waW5pb24gYWJvdXQgdGhlIA0KdXNlZnVsbmVzcy4gRG9u J3Qgc2VlIGEgcHJvYmxlbSBoZXJlLCBMSVNQIGlzIGEgZ29vZCBleGFtcGxlIGhvdyBpZ25v cmluZyANCnVua25vd24gZmxhZ3Mgd29ya3Mgd2VsbC4NCg0KDQpSZWdhcmRzLCBNYXJjDQoN Cg0KDQpPbiBTdW4sIDI3IEp1bCAyMDE0IDE3OjI4OjAxIC0wNzAwLCBUb20gSGVyYmVydCB3 cm90ZToNCj4gT24gU3VuLCBKdWwgMjcsIDIwMTQgYXQgMjoyMSBQTSwgRGlubyBGYXJpbmFj Y2kgPGZhcmluYWNjaUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IDIuIFRoZSBWWExBTi1HUEUg ZHJhZnQgc2hvdWxkIGZvY3VzIG9ubHkgb24gdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kIA0K Pj4+IHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCBwb3J0LiAgIFRoZSBm YWN0IHRoYXQgdGhlIFZYTEFOLUdQRSANCj4+PiBoZWFkZXIgY2xvc2VseSByZXNlbWJsZXMg VlhMQU4gbWF5IGJlIGNvbnZlbmllbnQgZm9yIGltcGxlbWVudGVycywgYnV0IA0KPj4+IHRo aXMgcHJvdG9jb2wgYnkgZGVmaW5pdGlvbiBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3 aXRoIFZYTEFOLg0KPj4gDQo+PiBJZiB5b3UgZG8gdGhhdCB0aGVuIGl0IHdpbGwgYmUgaGFy ZGVyIGZvciBWWExBTi1HUEUgc3lzdGVtcyB0byANCj4+IGludGVyb3BlcmF0ZSB3aXRoIGEg VlhMQU4gc3lzdGVtcy4gQmVjYXVzZSBhIFZYTEFOLUdQRSBzeXN0ZW0gd2lsbCBuZWVkIHRv IA0KPj4gb3BlbiBhbmQgbWFpbnRhaW4gMiBVRFAgc29ja2V0cy4gQW5kIGFuIGltcGxlbWVu dGFpdG9uIHdpbGwgaGF2ZSB0byBiZSANCj4+IGNhcmVmdWwgdG8gbm90IHNldCB0aGUgUC1i aXQgZm9yIHRoZSBWWExBTiBzb2NrZXQgb3IgY2xlYXIgdGhlIFAtYml0IGZvciANCj4+IFZY TEFOLUdQRSBzb2NrZXQuIFRoaXMgaXMgYWxsIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgYW5k IG9uZSB3YXkgb3IgdGhlIA0KPj4gb3RoZXIgc2hvdWxkIGJlIHVzZWQuDQo+PiANCj4gSSBh bSBub3Qgc3VyZSB3aGF0IHlvdSBhcmUgc3VnZ2VzdGluZy4gQUZBSUNUIHRoZXJlIGlzIG5v IGJhY2t3YXJkcw0KPiBjb21wYXRpYmxlIG1lYW5zIHRvIHRvIGFkZCB0aGUgcHJvdG9jb2wg ZmllbGQgdG8gVlhMQU4gd2hpY2ggaXMgdGhlDQo+IG1vdGl2YXRpb24gZm9yIHRoZSBuZXcg VURQIHBvcnQsIHdoaWNoIGluIHR1cm4gaW1wbGllcyBhIG5ldyBwcm90b2NvbA0KPiAod2hp Y2ggYWxzbyBpbXBsaWVzIGFuIG9wcG9ydHVuaXR5IHRvIGFkZCBhIG1vcmUgZ2VuZXJhbCBz ZXQgb2YNCj4gcHJvdG9jb2wgZmVhdHVyZXMgbGlrZSB2ZXJzaW9uIG51bWJlciBhbmQgb3B0 aW9ucyBleHRlbnNpb25zIHdoaWNoIGFyZQ0KPiBhbHNvIG5vdCBiYWNrd2FyZHMgY29tcGF0 aWJsZSkuIE1heWJlIGl0J3MgcG9zc2libGUgdG8gYnJlYWsNCj4gY29tcGF0aWJpbGl0eSB3 aXRoaW4gdGhlIHByb3RvY29sIGFuZCBhc3N1bWUgdGhhdCBvdXQgb2YgYmFuZA0KPiBtZWNo YW5pc21zIGNvdWxkIG5lZ290aWF0ZSB1c2Ugb2YgUC1iaXQgdG8gY29tcGVuc2F0ZSwgYnV0 IEkgYXNzdW1lDQo+IHRoZXJlJ3MgYWxyZWFkeSBxdWl0ZSBhIGJpdCBvZiBWWExBTiBkZXBs b3ltZW50IHNvIHRoYXQgc2VlbXMgcHJldHR5DQo+IHNoYWt5IHJvYnVzdG5lc3Mtd2lzZSB0 byBtZS4NCj4gDQo+IEl0J3Mgbm90IGp1c3QgYWRkaW5nIHRoZSBwcm90b2NvbCBmaWVsZCB0 aGF0IHdvdWxkIGJlIGFuIGlzc3VlLCBldmVuDQo+IGFkZGluZyB0aGUgT0FNIGJpdCB0byBW WExBTiB3b3VsZCBiZSBwcm9ibGVtYXRpYy4gUGVyIFZYTEFOIHNwZWMNCj4gdW5zcGVjaWZp ZWQgZmxhZyBiaXRzIGFyZSBpZ25vcmVkIG9uIHJlY2VpdmUsIHNvIGlmIHRoZSBPQU0gYml0 IHdlcmUNCj4gc3Vic2VxdWVudGx5IGRlZmluZWQgaW4gVlhMQU4gaXQgd2lsbCBiZSBpZ25v cmVkIGJ5IGV4aXN0aW5nDQo+IGltcGxlbWVudGF0aW9ucyBhbmQgdGhlc2UgcGFja2V0cyB3 aWxsIGJlIHByb2Nlc3NlZCBub3JtYWxseS0tIHRoaXMNCj4gc2VlbXMgdG8gYmUgaW5jb21w YXRpYmxlIHdpdGggdGhlIHByb3Bvc2VkIFZYTEFOLWdwZSByZXF1aXJlbWVudCB0aGF0DQo+ ICJXaGVuIHRoZSBPIGJpdCBpcyBzZXQgdG8gMSwgdGhlIHBhY2tldCBpcyBhbiBPQU0gcGFj a2V0IGFuZCBPQU0NCj4gcHJvY2Vzc2luZyBNVVNUIG9jY3VyLiIgKGJ0dyAnT0FNIHByb2Nl c3NpbmcnIGlzIGF3ZnVsbHkgYW1iaWd1b3VzIHRvDQo+IGJlIGEgTVVTVCBoZXJlIElNTyku DQo+IA0KPiBBbGxvd2luZyB0aGUgcmVzZXJ2ZWQgYml0cyBpbiB0aGUgaGVhZGVyIHRvIGJl IGlnbm9yZWQgb24gcmVjZWl2ZQ0KPiBsaW1pdHMgdGhlIHVzZWZ1bG5lc3MgaW4gdGhhdCBu ZXcgYml0cyB0aGF0IGFyZSBkZWZpbmVkIGNhbiBvbmx5IGJlDQo+IGFkdmlzb3J5IGFuZCBu b3QgZnVuZGFtZW50YWxseSBjaGFuZ2UgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHBhY2tldC4N Cj4gSGFkIHRoZSByZXF1aXJlbWVudCBpbiBWWExBTiBiZWVuIHRoYXQgcGFja2V0cyB3aXRo IHVua25vd24gYml0cyBzZXQNCj4gYmUgZHJvcHBlZCwgdGhlbiBhZGRpbmcgUC1iaXQgYW5k IE8tYml0IGNvdWxkIGhhdmUgYmVlbiBkb25lIHdpdGgNCj4gYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuIFRoaXMgbWlnaHQgYmUgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IHRvDQo+IGNv bnNpZGVyIGlmIG5ldyBwcm90b2NvbCAoaS5lLiBuZXcgcG9ydCBudW1iZXIpIGlzIHVuZGVy dGFrZW4uDQo+IA0KPiBUaGFua3MsDQo+IFRvbQ0KPiANCj4+IEFuZCBpZiAqaXQgd2FzIGFn cmVlZCogb24gdG8gdXNlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJzIChsaWtlIHRoZSB3 YXkgDQo+PiBMSVNQIGRpZCBpdCBmb3IgTDIgdmVyc3VzIEwzIHBhY2tldCBlbmNhcHN1bGF0 aW9uKSwgd2Ugd291bGRuJ3QgbmVlZCB0aGUgDQo+PiBQLWJpdCBhdCBhbGwuIEJ1dCB0aGVy ZSB3YXMgcHVzaCBiYWNrIChieSBzb21lYm9keSkgdG8gbm90IGFsbG9jYXRlIA0KPj4gYW5v dGhlciBwb3J0IGZvciBWWExBTiwgc28gdGhlIGRlbXV4IHdhcyBmb3JjZWQgdG8gYmUgaW4g dGhlIFZYTEFOIGhlYWRlci4NCj4+IA0KPj4gQW5kIGlzIGFsc28gdGhlIHJlYXNvbiB0aGlz IGJhZ2dhZ2UgaXMgYmVpbmcgY2FycmllZCBvdmVyIHRoZSBMSVNQIHdoZW4gaXQgDQo+PiBy ZWFsbHkgaXNuJ3QgbmVlZGVkLg0KPj4gDQo+Pj4gMy4gVHJ1ZSwgdGhlIKFQoiBiaXQgaXMg bm90IG5lZWRlZCBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgYnV0IEmibSANCj4+PiBu b3QgYWdhaW5zdCBpdCBpZiB0aGVyZSBpcyB2YWx1ZSB0byBtYWtlIGl0IGNvbnNpc3RlbnQg d2l0aCB0aGUgTElTUC1HUEUgDQo+Pj4gaGVhZGVyLg0KPj4gDQo+PiBUaGVyZSBpcyBubyBp bmNyZW1lbnRhbCBiZW5lZml0IHRvIHVzZSB0aGUgUC1iaXQgZm9yIExJU1AuIFdlIGhhZCBh IA0KPj4gc29sdXRpb24gYnV0IGJlY2F1c2Ugb2YgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUg bm8gbmV3IHBvcnQgZm9yIFZYTEFOLCANCj4+IExJU1AgaXMgYWZmZWN0ZWQuDQo+PiANCj4+ IEp1c3QgYW5vdGhlciBleGFtcGxlIGhvdyB0aGUgd29ya2luZyBncm91cCBpcyBwdXR0aW5n IGVmZm9ydCBpbnRvIHRoaW5ncyANCj4+IHRoYXQgY3JlYXRlcyBtb3JlIHdvcmsgYnV0IG5v IGJlbmVmaXQuIERvbid0IGdldCBtZSB3cm9uZywgdGhlIGNpc2NvIGd1eXMgDQo+PiBkaWQg dGhpcyAodGhlIFZYTEFOIGFuZCBMSVNQIHNhbWUgcG9zaXRpb24gZm9yIFAtYml0KSBmb3Ig Y29uc2lzdGVuY3ksIGFuZCANCj4+IHRoZXkgc2hvdWxkIGJlIGFwcGxhdWRlZCBmb3IgdGhh dC4gQnV0IGlmIFZYTEFOIGNvdWxkIGhhdmUgYW5vdGhlciBwb3J0IA0KPj4gbnVtYmVyIGFz c2lnbmVkIGZvciAib3RoZXIgcHJvdG9jb2xzIiwgbWF5YmUgdGhlIFZYTEFOLUdQRSB3b3Vs ZCBsb29rIHNvIA0KPj4gbXVjaCBkaWZmZXJlbnQuDQo+PiANCj4+IFNvbWV0aGluZyB0byB0 aGluayBhYm91dCBhcyB0aGUgd29ya2luZyBncm91cCBub3cgaGFzIG5ldyBwcm9kdWN0aXZp dHkgDQo+PiBtZW50YWxpdHkuDQo+PiANCj4+IERpbm8NCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG52bzMgbWFpbGluZyBs aXN0DQo+PiBudm8zQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL252bzMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8z From nobody Mon Jul 28 03:14:19 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE4E1A0382; Mon, 28 Jul 2014 03:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmZ3Ws-0mBCT; Mon, 28 Jul 2014 03:14:04 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6A91A036C; Mon, 28 Jul 2014 03:14:03 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so6451825ieb.18 for ; Mon, 28 Jul 2014 03:14:03 -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=ZEkHpEauRBXR2i8nDtysMvn2/0Ch1jQhs4Puk77j+pY=; b=oC5n8Y9pIr2E75R/Y5FXNa/jmrmim/rjXaGI+RLAznBMOXXvXNUW10p8UbiqAOsGlr YBjT4i2IyWL+EclPsko1VumDu0UTEAkTG1lyjXsn8a8K2L41Lqgl/kWdLtHdhFEQv7EO NQFWi0ss52nfkiObuwkd3sfEDLmMIbJdsPl9COf8+pN+NWcTIfwP4jwrTSOBqRcDSKPk tiop7nwFM0wSYmBJLd/3lm/JgU4WgCchYEv19vBCn9uIB8/PQPigYbpqBT7VZQ3R0ZUA tMG48Gykp5UEjzuDTdmqfEO0RQ6rl2Osvwl4WZMKHBTTGYmvLSmD11nNxG5C25dPizf9 UQeQ== X-Received: by 10.50.50.175 with SMTP id d15mr30495310igo.35.1406542443289; Mon, 28 Jul 2014 03:14:03 -0700 (PDT) Received: from [10.173.63.228] ([166.137.94.111]) by mx.google.com with ESMTPSA id bf4sm25396212igb.17.2014.07.28.03.14.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 03:14:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <20140727235848276183.21b2fe35@sniff.de> Date: Mon, 28 Jul 2014 06:14:02 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> To: Marc Binderberger Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/ai5bMK-s-xwWeNXxLXDcpw7XElg Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:14:07 -0000 > The point Dino makes is (I think): is there really a gain to "re-invent" > VxLAN and LISP data encapsulation? And it might be actually easier to > implement and test separate encodings instead of the more complex combined > header in VxLAN-gpe. Exactly. Dino From nobody Mon Jul 28 03:19:08 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7696B1A038B for ; Mon, 28 Jul 2014 03:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2pzWIA10Nfx for ; Mon, 28 Jul 2014 03:19:05 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754C61A0397 for ; Mon, 28 Jul 2014 03:19:05 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so3966241wiw.5 for ; Mon, 28 Jul 2014 03:19:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references; bh=QsG21XA2ebYdIo/h6Rn4pmRygMCKxSlL81IdfgL3dZQ=; b=V5rqbwfer5+Z6XQCyd3eBsRNZWwfOoZRZjgIOHDYbQEfidPNB75p6yfrkeikYbGz3k M1x3gqCXVWhXNSQBYyWum65UYDQ8nmdGX4oajf5yvCb9f1PRCl50apXcS0ftmSqppodD ieGQxo2P7p04jcudZI+dMvkj6DwJ5kecU0ZG9YgZOxpugZfn1C1UJ/qs3dgAWGHMDaoE FzsfFkbD6paqE8QlbeCuNPR9uxj8RAz3PkGDD9SsE54++Tx7cKcfxLClWa5Szt1s3Htg 9Aj0cmbT2a0GCdxI5soY2iNIUgYGT5htGUu1WzksoXU9gsQwYCWQpLJEIhNlm9Ro9XTY 5PJQ== X-Gm-Message-State: ALoCoQn7xXP2o9hBaX1M9xoqDej3eN7Ns0eWn25j5ucnRo+f3p2fyAbpGNlXOCIiv+EQPcmmeO6k X-Received: by 10.180.212.77 with SMTP id ni13mr29215485wic.42.1406542742575; Mon, 28 Jul 2014 03:19:02 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:8599:322a:d923:66a3? ([2001:660:330f:a4:8599:322a:d923:66a3]) by mx.google.com with ESMTPSA id v14sm48399484wjw.38.2014.07.28.03.19.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 03:19:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Luigi Iannone In-Reply-To: <53D2550D.4080906@innovationslab.net> Date: Mon, 28 Jul 2014 12:19:15 +0200 Cc: "lisp@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <53D2550D.4080906@innovationslab.net> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/n9kNUGe4JLCVCCAI6sAQNESbVCU Subject: Re: [lisp] Terry stepping down as co-chair X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:19:06 -0000 A big thanks to Terry for all his commitment in those years. Luigi On 25 Jul 2014, at 15:01, Brian Haberman wrote: > All, > For those of you who were not able to be in Toronto, Terry is > stepping down as co-chair. I want to thank Terry for filling this role > so admirably for the past 4.5+ years. > > Regards, > Brian > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jul 28 06:15:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE31A01C6; Mon, 28 Jul 2014 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgMSDyPGhkXf; Mon, 28 Jul 2014 06:15:40 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5101A0059; Mon, 28 Jul 2014 06:15:40 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so6636951iec.3 for ; Mon, 28 Jul 2014 06:15:39 -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=P7CMWFUw+1DqD0c9AthcYZXNfzI2F5H16tePyhpEAzk=; b=fUJ9N2EKBNOX1pRHvrIz9fszC+bIlvXdFmqmp2yijuHeqGhif2uS+/8JqNbnHMrf47 0n2fBDXB2/eOZnWI86ptnw9G8g+XTp1JU4arlOwtGJ8veJxQeKlt62Ru/n0NF8ZpI6/U ozYWJLRteMpHyzcTw24+7Ublf73pFNMuZT4K3UHA/jpYvMLfgbKXxcO93YO8RpyLQebE IX6aGM1EWkeLgGqDKQi+6v+4bEaw3Ijay2nt5YAs1OzFpRMER/XxXgXJijdBb0UXP5xi VrqdH/mptsZqbmILV6RobVsgMBIzZ3KH72vybVXJCFIGCzEy6OCvKEdPqAEP5ee1Q/kX 6qiQ== X-Received: by 10.42.208.70 with SMTP id gb6mr4611533icb.89.1406553339502; Mon, 28 Jul 2014 06:15:39 -0700 (PDT) Received: from [10.152.209.141] (mobile-166-147-102-232.mycingular.net. [166.147.102.232]) by mx.google.com with ESMTPSA id i6sm26719947igu.15.2014.07.28.06.15.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 06:15:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Mon, 28 Jul 2014 08:15:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/NzbDDjytv3Ma1954pnqx8qGj-Qk Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] =?utf-8?b?562U5aSNOiBbbnZvM10gQ29tbWVudHMgb24gaHR0cDovL3Rv?= =?utf-8?q?ols=2Eietf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:15:44 -0000 > On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >=20 > About backward compatibility, i also agree with Dino. VXLAN-GPE should foc= us on the VXLAN-GPE header and requires the assignment of a new UDP port, t= he data format don't need consider backward compatibility with VXLAN header.= I I want to make it clear that supporting backward compatibility is very impor= tant since VXLAN-port-4789 is supported in various chips already.=20 Dino From nobody Mon Jul 28 07:18:27 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5CF1B282E; Mon, 28 Jul 2014 07:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkbJQW64_dKh; Mon, 28 Jul 2014 07:18:24 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D416E1B2829; Mon, 28 Jul 2014 07:18:23 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so6465922ieb.7 for ; Mon, 28 Jul 2014 07:18:23 -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=TelHGi+z3MYwTP71GPq/gvU34oupiOw93caMBUl/vLs=; b=y8OqsxrRY//i6KTsavOfQ3gF8jYJD01xAbSnPHVb92ZHCtiXoXVa8sEp/w3iKAHLx/ Po6TGfXzvKByo2zrQ7auRMf3hra8ggKrzdEK+la5PXpZ3x6H3cQ1WfOK16uV7Sv4NP3X FjuQ1wQoVYhA6JIBHBn8Bbcc33xDuiHKgAVpJVGFjXO+AxMb2K0Y6Uxmtxs7/OG5Jriy vfgPXOQSqkB1S5eSBi/ny6ln9DPGG0o18Papx2pAzHcl4Jh/1R6le/tWue/nyUCRoLNq PZtCDnDlUy7ZNvzyJbCyWDHABYeHOUNhX0okeaHwCnty51K/+XTHUbhidA9intyRSu0C 1u4A== X-Received: by 10.50.8.6 with SMTP id n6mr15025759iga.43.1406557103293; Mon, 28 Jul 2014 07:18:23 -0700 (PDT) Received: from [172.19.131.148] ([12.130.116.26]) by mx.google.com with ESMTPSA id tp2sm27211960igb.7.2014.07.28.07.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 07:18:22 -0700 (PDT) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 28 Jul 2014 07:17:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

, <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> To: Haoweiguo X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/PEBZuudoTKbIOKHst6LRd0DabYU Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:18:25 -0000 > Hi Dino, > Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP = port and a new data format, P bit=20 No worries.=20 > in VXLAN-GPE seems to have no any value. As for basic inter-subnet = layer 3 communication and intra-subnet layer 2 communication between = NVEs, current NVGRE, VXLAN and LISP have already supported,=20 VXLAN supports L2 overlays since its goal is to extend subnets. LISP = supports L3 overlays so it assumes subnets are local (to the xTR) just = like in a routed network. NVGRE can be a combo. > NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 = network if only basic layer 3 and=20 There is motivation to extend an encapsulation header (which is called = VXLAN-GPE) so it can support, most importantly NSH. That change also = gives VXLAN to support encapsulating layer-2 IPv4 and IPv6, which is = duplicate functionality of LISP. But the headers are so similar, it = really doens't matter. However, the P-bit is not needed for anything new in LISP and the = OAM-bit is not needed in LISP since LISP has different UDP port number = (4342) for control-packets. VXLAN does not have a well defined control = protocol so the data-plane has to escape out control-plane pakcets where = the first one is this new OAM message. > layer 2 forwarding process exists. As for some extra functions of OAM, = service chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE = network should be used in these cases. > Thanks > weiguo Right, agree. Dino >=20 >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: Dino Farinacci [farinacci@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C228=C8=D5 21:15 > =CA=D5=BC=FE=C8=CB: Haoweiguo > =B3=AD=CB=CD: Tom Herbert; David Melman; nvo3@ietf.org; LISP mailing = list list > =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [nvo3] Comments on = http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 >> On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >>=20 >> About backward compatibility, i also agree with Dino. VXLAN-GPE = should focus on the VXLAN-GPE header and requires the assignment of a = new UDP port, the data format don't need consider backward compatibility = with VXLAN header. I >=20 > I want to make it clear that supporting backward compatibility is very = important since VXLAN-port-4789 is supported in various chips already. >=20 > Dino From nobody Mon Jul 28 09:23:26 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448F71B27C4 for ; Sun, 27 Jul 2014 17:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUjvcbKPq2Wy for ; Sun, 27 Jul 2014 17:28:02 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FA81B27C3 for ; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so5972541iec.15 for ; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d76G85O9OmXafTuCXgBRA9Q+cOQY9qX3stEh+96oi24=; b=mfOcQLR5OINTwmBKKXVlsZ3goXL9K3ZhBCzlDKLm2zbmefqBH6ie864o/EenAZv6u0 +WchPLhc4wncJ9E4zHZw4t+ImpXVygU655/9+D3Ser8TYQvUUtyGdeI1zCdioNRmacVi WigJFsIUlI0btwxdyG4cGVaOnxUBPAqI8vqTJd7fSW5TOwE+TOz1J+JZmNB/YKKEt1ie 3EUC2jzzhUwdtLHs4UZjxYoPgqRjw5cRhWdG8kcyzpyfjzJBBaef/tL/6C83BoPYfqNz XZ1k2o4XzGFTDMOeGhNuunWHmPxE2BHbvJMqIBs+XmfPUZ3zefpweM5ojkYp4nV2PHNj E6bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d76G85O9OmXafTuCXgBRA9Q+cOQY9qX3stEh+96oi24=; b=HR27P3G25vyzse+VWxAnHBAmthpPKJcq1S5Fk3UbmFDEieFXN8AJ5NqYuWjbkjUaLu NnhYV45HeoOy+DNLmW1LbR5myjC23H3ZyxQemZkPp4LKRiGt7HSoOVlA/C2xpefB/Kh2 CS+noMmyRwyjHxwNJzHG2xV2IEyTqdcpCWmZPhGaU1rbsZ5SCjZtGERjfi8tpO+Hniab 1yvNbgeZ4OyYL55Qo5kIlEVk5h2qxlKmJvFTQ7dgpMhrsgy1axKX9BeapsXZtaBZdZJO SEo7wF/jr/JU2Gh1+Mw+/81TxGqHYxmP+teu702LpzVza8Qn+67u6WpAWCPfAfHiDn9s 25nQ== X-Gm-Message-State: ALoCoQlwrDGWMdfiBmVGnFGbT2aWAA9R1XAeyW8Ddh7JFbgNvJ0NE4tZJH7enTJ4R83aL9a1yKCj MIME-Version: 1.0 X-Received: by 10.50.43.234 with SMTP id z10mr26894404igl.28.1406507281221; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Sun, 27 Jul 2014 17:28:01 -0700 (PDT) In-Reply-To: <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> Date: Sun, 27 Jul 2014 17:28:01 -0700 Message-ID: From: Tom Herbert To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/U-EcGrKSJPhDNcwfntaSj4UpwZ8 X-Mailman-Approved-At: Mon, 28 Jul 2014 09:23:16 -0700 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 00:28:03 -0000 On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrote= : >> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and req= uires the assignment of a new UDP port. The fact that the VXLAN-GPE heade= r closely resembles VXLAN may be convenient for implementers, but this prot= ocol by definition is not backward compatible with VXLAN. > > If you do that then it will be harder for VXLAN-GPE systems to interopera= te with a VXLAN systems. Because a VXLAN-GPE system will need to open and m= aintain 2 UDP sockets. And an implementaiton will have to be careful to not= set the P-bit for the VXLAN socket or clear the P-bit for VXLAN-GPE socket= . This is all completely unnecessary and one way or the other should be use= d. > I am not sure what you are suggesting. AFAICT there is no backwards compatible means to to add the protocol field to VXLAN which is the motivation for the new UDP port, which in turn implies a new protocol (which also implies an opportunity to add a more general set of protocol features like version number and options extensions which are also not backwards compatible). Maybe it's possible to break compatibility within the protocol and assume that out of band mechanisms could negotiate use of P-bit to compensate, but I assume there's already quite a bit of VXLAN deployment so that seems pretty shaky robustness-wise to me. It's not just adding the protocol field that would be an issue, even adding the OAM bit to VXLAN would be problematic. Per VXLAN spec unspecified flag bits are ignored on receive, so if the OAM bit were subsequently defined in VXLAN it will be ignored by existing implementations and these packets will be processed normally-- this seems to be incompatible with the proposed VXLAN-gpe requirement that "When the O bit is set to 1, the packet is an OAM packet and OAM processing MUST occur." (btw 'OAM processing' is awfully ambiguous to be a MUST here IMO). Allowing the reserved bits in the header to be ignored on receive limits the usefulness in that new bits that are defined can only be advisory and not fundamentally change interpretation of the packet. Had the requirement in VXLAN been that packets with unknown bits set be dropped, then adding P-bit and O-bit could have been done with backwards compatibility. This might be a reasonable requirement to consider if new protocol (i.e. new port number) is undertaken. Thanks, Tom > And if *it was agreed* on to use different UDP port numbers (like the way= LISP did it for L2 versus L3 packet encapsulation), we wouldn't need the P= -bit at all. But there was push back (by somebody) to not allocate another = port for VXLAN, so the demux was forced to be in the VXLAN header. > > And is also the reason this baggage is being carried over the LISP when i= t really isn't needed. > >> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward compatib= ility, but I=E2=80=99m not against it if there is value to make it consiste= nt with the LISP-GPE header. > > There is no incremental benefit to use the P-bit for LISP. We had a solut= ion but because of the requirement to have no new port for VXLAN, LISP is a= ffected. > > Just another example how the working group is putting effort into things = that creates more work but no benefit. Don't get me wrong, the cisco guys d= id this (the VXLAN and LISP same position for P-bit) for consistency, and t= hey should be applauded for that. But if VXLAN could have another port numb= er assigned for "other protocols", maybe the VXLAN-GPE would look so much d= ifferent. > > Something to think about as the working group now has new productivity me= ntality. > > Dino > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon Jul 28 09:23:28 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7F31A0515; Mon, 28 Jul 2014 05:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzpZchegv3jF; Mon, 28 Jul 2014 05:24:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7601A0174; Mon, 28 Jul 2014 05:24:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKP64751; Mon, 28 Jul 2014 12:24:22 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Jul 2014 13:24:22 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 20:24:16 +0800 From: Haoweiguo To: Dino Farinacci , Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqkzAsneDBkHiT0W0YABoAmZP/5u1ZM/Q Date: Mon, 28 Jul 2014 12:24:15 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.12.133] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Ye00Pw7-FGsuxu_L9fmsuJTF2HI X-Mailman-Approved-At: Mon, 28 Jul 2014 09:23:05 -0700 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: [lisp] =?gb2312?b?tPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90?= =?gb2312?b?b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:24:27 -0000 QWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaSBhbHNvIGFncmVlIHdpdGggRGluby4gVlhM QU4tR1BFIHNob3VsZCBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kIHJlcXVpcmVz IHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCBwb3J0LCB0aGUgZGF0YSBmb3JtYXQgZG9uJ3Qg bmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggVlhMQU4gaGVhZGVyLiBJ ZiBOVkUxIHN1cHBvcnQgVlhMQU4tR1BFLCBhbm90aGVyIE5WRTIgc3VwcG9ydCBWWExBTiwgdGhl IHR3byBOVkUgY2FuIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlciwgbm8gbWF0dGVyIGludGVy LXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgb3IgaW50cmEtc3VibmV0IGxheWVyIDIgdHJhZmZpYy4N CldoZW4gaW5ncmVzcyBOVkUgc2VuZHMgdHJhZmZpYyB0byBlZ3Jlc3MgTlZFLCBpbmdyZXNzIE5W RSBzaG91bGQgdXNlIHRoZSBkYXRhIGZvcm1hdCBvZiBlZ3Jlc3MgTlZFLCBpLmUuLCB3aGVuIE5W RTEgc2VuZHMgdHJhZmZpYyB0byBOVkUyLCBOVkUxIHNob3VsZCB1c2UgVlhMQU4gZW5jYXBzdWxh dGlvbi4gV2hlbiBOVkUyIHNlbmRzIHRyYWZmaWMgdG8gTlZFMSwgTlZFMSBzaG91bGQgdXNlIFZY TEFOLUdQRSBoZWFkZXIuDQpBbHRob3VnaCBWWExBTiBjdXJyZW50bHkgb25seSBzdXBwb3J0IEV0 aGVybmV0IGluIFVEUCwgIGxheWVyIDMgaW50ZXItc3VibmV0IHRyYWZmaWMgZm9yd2FyZGluZyBi ZXR3ZWVuIE5WRXMgY2FuIGFsc28gYmUgc3VwcG9ydGVkLCBpbm5lciBkZXN0aW5hdGlvbiBNQUMg Y2FuIGJlIHVzZWQgdG8gZGlmZmVyZW5jaWF0ZSBpbnRlci1zdWJuZXQgbGF5ZXIgMyB0cmFmZmlj IGZyb20gaW50cmEtc3VibmV0IGxheWVyIDIgdHJhZmZpYyBvbiBlZ3Jlc3MgTlZFLCBpbm5lciBk ZXN0aW5hdGlvbiBNQUMgc2hvdWxkIGJlIHNldCBnYXRld2F5IGludGVyZmFjZSBNQUMgb2YgZWdy ZXNzIE5WRSBpbiBpbnRlci1zdWJuZXQgY29tbXVuaWNhdGlvbiBjYXNlLg0KVGhhbmtzDQp3ZWln dW8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGlu byBGYXJpbmFjY2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCMjjI 1SA4OjM5DQrK1bz+yMs6IFRvbSBIZXJiZXJ0DQqzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0 Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCtb3zOI6IFJlOiBbbnZvM10gQ29tbWVudHMg b24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQoN CkkgYW0gZ29pbmcgdG8gbGV0IG90aGVyIHBlb3BsZSBleHBsYWluLiBJIHRoaW5rIG15IGVtYWls IHdhcyBjbGVhci4NCg0KRGlubw0KDQo+IE9uIEp1bCAyNywgMjAxNCwgYXQgODoyOCBQTSwgVG9t IEhlcmJlcnQgPHRoZXJiZXJ0QGdvb2dsZS5jb20+IHdyb3RlOg0KPg0KPiBPbiBTdW4sIEp1bCAy NywgMjAxNCBhdCAyOjIxIFBNLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4g d3JvdGU6DQo+Pj4gMi4gVGhlIFZYTEFOLUdQRSBkcmFmdCBzaG91bGQgZm9jdXMgb25seSBvbiB0 aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVxdWlyZXMgdGhlIGFzc2lnbm1lbnQgb2YgYSBuZXcg VURQIHBvcnQuICAgVGhlIGZhY3QgdGhhdCB0aGUgVlhMQU4tR1BFIGhlYWRlciBjbG9zZWx5IHJl c2VtYmxlcyBWWExBTiBtYXkgYmUgY29udmVuaWVudCBmb3IgaW1wbGVtZW50ZXJzLCBidXQgdGhp cyBwcm90b2NvbCBieSBkZWZpbml0aW9uIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGgg VlhMQU4uDQo+Pg0KPj4gSWYgeW91IGRvIHRoYXQgdGhlbiBpdCB3aWxsIGJlIGhhcmRlciBmb3Ig VlhMQU4tR1BFIHN5c3RlbXMgdG8gaW50ZXJvcGVyYXRlIHdpdGggYSBWWExBTiBzeXN0ZW1zLiBC ZWNhdXNlIGEgVlhMQU4tR1BFIHN5c3RlbSB3aWxsIG5lZWQgdG8gb3BlbiBhbmQgbWFpbnRhaW4g MiBVRFAgc29ja2V0cy4gQW5kIGFuIGltcGxlbWVudGFpdG9uIHdpbGwgaGF2ZSB0byBiZSBjYXJl ZnVsIHRvIG5vdCBzZXQgdGhlIFAtYml0IGZvciB0aGUgVlhMQU4gc29ja2V0IG9yIGNsZWFyIHRo ZSBQLWJpdCBmb3IgVlhMQU4tR1BFIHNvY2tldC4gVGhpcyBpcyBhbGwgY29tcGxldGVseSB1bm5l Y2Vzc2FyeSBhbmQgb25lIHdheSBvciB0aGUgb3RoZXIgc2hvdWxkIGJlIHVzZWQuDQo+IEkgYW0g bm90IHN1cmUgd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcuIEFGQUlDVCB0aGVyZSBpcyBubyBiYWNr d2FyZHMNCj4gY29tcGF0aWJsZSBtZWFucyB0byB0byBhZGQgdGhlIHByb3RvY29sIGZpZWxkIHRv IFZYTEFOIHdoaWNoIGlzIHRoZQ0KPiBtb3RpdmF0aW9uIGZvciB0aGUgbmV3IFVEUCBwb3J0LCB3 aGljaCBpbiB0dXJuIGltcGxpZXMgYSBuZXcgcHJvdG9jb2wNCj4gKHdoaWNoIGFsc28gaW1wbGll cyBhbiBvcHBvcnR1bml0eSB0byBhZGQgYSBtb3JlIGdlbmVyYWwgc2V0IG9mDQo+IHByb3RvY29s IGZlYXR1cmVzIGxpa2UgdmVyc2lvbiBudW1iZXIgYW5kIG9wdGlvbnMgZXh0ZW5zaW9ucyB3aGlj aCBhcmUNCj4gYWxzbyBub3QgYmFja3dhcmRzIGNvbXBhdGlibGUpLiBNYXliZSBpdCdzIHBvc3Np YmxlIHRvIGJyZWFrDQo+IGNvbXBhdGliaWxpdHkgd2l0aGluIHRoZSBwcm90b2NvbCBhbmQgYXNz dW1lIHRoYXQgb3V0IG9mIGJhbmQNCj4gbWVjaGFuaXNtcyBjb3VsZCBuZWdvdGlhdGUgdXNlIG9m IFAtYml0IHRvIGNvbXBlbnNhdGUsIGJ1dCBJIGFzc3VtZQ0KPiB0aGVyZSdzIGFscmVhZHkgcXVp dGUgYSBiaXQgb2YgVlhMQU4gZGVwbG95bWVudCBzbyB0aGF0IHNlZW1zIHByZXR0eQ0KPiBzaGFr eSByb2J1c3RuZXNzLXdpc2UgdG8gbWUuDQo+DQo+IEl0J3Mgbm90IGp1c3QgYWRkaW5nIHRoZSBw cm90b2NvbCBmaWVsZCB0aGF0IHdvdWxkIGJlIGFuIGlzc3VlLCBldmVuDQo+IGFkZGluZyB0aGUg T0FNIGJpdCB0byBWWExBTiB3b3VsZCBiZSBwcm9ibGVtYXRpYy4gUGVyIFZYTEFOIHNwZWMNCj4g dW5zcGVjaWZpZWQgZmxhZyBiaXRzIGFyZSBpZ25vcmVkIG9uIHJlY2VpdmUsIHNvIGlmIHRoZSBP QU0gYml0IHdlcmUNCj4gc3Vic2VxdWVudGx5IGRlZmluZWQgaW4gVlhMQU4gaXQgd2lsbCBiZSBp Z25vcmVkIGJ5IGV4aXN0aW5nDQo+IGltcGxlbWVudGF0aW9ucyBhbmQgdGhlc2UgcGFja2V0cyB3 aWxsIGJlIHByb2Nlc3NlZCBub3JtYWxseS0tIHRoaXMNCj4gc2VlbXMgdG8gYmUgaW5jb21wYXRp YmxlIHdpdGggdGhlIHByb3Bvc2VkIFZYTEFOLWdwZSByZXF1aXJlbWVudCB0aGF0DQo+ICJXaGVu IHRoZSBPIGJpdCBpcyBzZXQgdG8gMSwgdGhlIHBhY2tldCBpcyBhbiBPQU0gcGFja2V0IGFuZCBP QU0NCj4gcHJvY2Vzc2luZyBNVVNUIG9jY3VyLiIgKGJ0dyAnT0FNIHByb2Nlc3NpbmcnIGlzIGF3 ZnVsbHkgYW1iaWd1b3VzIHRvDQo+IGJlIGEgTVVTVCBoZXJlIElNTykuDQo+DQo+IEFsbG93aW5n IHRoZSByZXNlcnZlZCBiaXRzIGluIHRoZSBoZWFkZXIgdG8gYmUgaWdub3JlZCBvbiByZWNlaXZl DQo+IGxpbWl0cyB0aGUgdXNlZnVsbmVzcyBpbiB0aGF0IG5ldyBiaXRzIHRoYXQgYXJlIGRlZmlu ZWQgY2FuIG9ubHkgYmUNCj4gYWR2aXNvcnkgYW5kIG5vdCBmdW5kYW1lbnRhbGx5IGNoYW5nZSBp bnRlcnByZXRhdGlvbiBvZiB0aGUgcGFja2V0Lg0KPiBIYWQgdGhlIHJlcXVpcmVtZW50IGluIFZY TEFOIGJlZW4gdGhhdCBwYWNrZXRzIHdpdGggdW5rbm93biBiaXRzIHNldA0KPiBiZSBkcm9wcGVk LCB0aGVuIGFkZGluZyBQLWJpdCBhbmQgTy1iaXQgY291bGQgaGF2ZSBiZWVuIGRvbmUgd2l0aA0K PiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gVGhpcyBtaWdodCBiZSBhIHJlYXNvbmFibGUgcmVx dWlyZW1lbnQgdG8NCj4gY29uc2lkZXIgaWYgbmV3IHByb3RvY29sIChpLmUuIG5ldyBwb3J0IG51 bWJlcikgaXMgdW5kZXJ0YWtlbi4NCj4NCj4gVGhhbmtzLA0KPiBUb20NCj4NCj4+IEFuZCBpZiAq aXQgd2FzIGFncmVlZCogb24gdG8gdXNlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJzIChsaWtl IHRoZSB3YXkgTElTUCBkaWQgaXQgZm9yIEwyIHZlcnN1cyBMMyBwYWNrZXQgZW5jYXBzdWxhdGlv biksIHdlIHdvdWxkbid0IG5lZWQgdGhlIFAtYml0IGF0IGFsbC4gQnV0IHRoZXJlIHdhcyBwdXNo IGJhY2sgKGJ5IHNvbWVib2R5KSB0byBub3QgYWxsb2NhdGUgYW5vdGhlciBwb3J0IGZvciBWWExB Tiwgc28gdGhlIGRlbXV4IHdhcyBmb3JjZWQgdG8gYmUgaW4gdGhlIFZYTEFOIGhlYWRlci4NCj4+ DQo+PiBBbmQgaXMgYWxzbyB0aGUgcmVhc29uIHRoaXMgYmFnZ2FnZSBpcyBiZWluZyBjYXJyaWVk IG92ZXIgdGhlIExJU1Agd2hlbiBpdCByZWFsbHkgaXNuJ3QgbmVlZGVkLg0KPj4NCj4+PiAzLiBU cnVlLCB0aGUgoa5Qoa8gYml0IGlzIG5vdCBuZWVkZWQgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHksIGJ1dCBJoa9tIG5vdCBhZ2FpbnN0IGl0IGlmIHRoZXJlIGlzIHZhbHVlIHRvIG1ha2UgaXQg Y29uc2lzdGVudCB3aXRoIHRoZSBMSVNQLUdQRSBoZWFkZXIuDQo+Pg0KPj4gVGhlcmUgaXMgbm8g aW5jcmVtZW50YWwgYmVuZWZpdCB0byB1c2UgdGhlIFAtYml0IGZvciBMSVNQLiBXZSBoYWQgYSBz b2x1dGlvbiBidXQgYmVjYXVzZSBvZiB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBubyBuZXcgcG9y dCBmb3IgVlhMQU4sIExJU1AgaXMgYWZmZWN0ZWQuDQo+Pg0KPj4gSnVzdCBhbm90aGVyIGV4YW1w bGUgaG93IHRoZSB3b3JraW5nIGdyb3VwIGlzIHB1dHRpbmcgZWZmb3J0IGludG8gdGhpbmdzIHRo YXQgY3JlYXRlcyBtb3JlIHdvcmsgYnV0IG5vIGJlbmVmaXQuIERvbid0IGdldCBtZSB3cm9uZywg dGhlIGNpc2NvIGd1eXMgZGlkIHRoaXMgKHRoZSBWWExBTiBhbmQgTElTUCBzYW1lIHBvc2l0aW9u IGZvciBQLWJpdCkgZm9yIGNvbnNpc3RlbmN5LCBhbmQgdGhleSBzaG91bGQgYmUgYXBwbGF1ZGVk IGZvciB0aGF0LiBCdXQgaWYgVlhMQU4gY291bGQgaGF2ZSBhbm90aGVyIHBvcnQgbnVtYmVyIGFz c2lnbmVkIGZvciAib3RoZXIgcHJvdG9jb2xzIiwgbWF5YmUgdGhlIFZYTEFOLUdQRSB3b3VsZCBs b29rIHNvIG11Y2ggZGlmZmVyZW50Lg0KPj4NCj4+IFNvbWV0aGluZyB0byB0aGluayBhYm91dCBh cyB0aGUgd29ya2luZyBncm91cCBub3cgaGFzIG5ldyBwcm9kdWN0aXZpdHkgbWVudGFsaXR5Lg0K Pj4NCj4+IERpbm8NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+IG52bzNAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw== From nobody Mon Jul 28 09:23:29 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831C11B2812; Mon, 28 Jul 2014 06:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP-yAGT4kVs3; Mon, 28 Jul 2014 06:55:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8BE1A03FD; Mon, 28 Jul 2014 06:55:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR11598; Mon, 28 Jul 2014 13:55:52 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Jul 2014 14:55:51 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 21:55:47 +0800 From: Haoweiguo To: Dino Farinacci Thread-Topic: =?gb2312?B?tPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5pZXRmLm9y?= =?gb2312?Q?g/html/draft-quinn-vxlan-gpe-03?= Thread-Index: AQHPqkzAsneDBkHiT0W0YABoAmZP/5u1ZM/Q//+MiICAAIxMcg== Date: Mon, 28 Jul 2014 13:55:46 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

, <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> In-Reply-To: <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.2.229] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/qvl3AzoH744PlugIAA3ZfGChtys X-Mailman-Approved-At: Mon, 28 Jul 2014 09:23:10 -0700 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [lisp] =?gb2312?b?tPC4tDogtPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0?= =?gb2312?b?dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdw?= =?gb2312?b?ZS0wMw==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:55:55 -0000 SGkgRGlubywNClNvcnJ5LCBpIG1pc3VuZGVyc3Rvb2QgeW91LiBJIHRoaW5rIFZYTEFOLUdQRSBj YW4gZGVmaW5lIGEgbmV3IFVEUCBwb3J0IGFuZCBhIG5ldyBkYXRhIGZvcm1hdCwgUCBiaXQgaW4g VlhMQU4tR1BFIHNlZW1zIHRvIGhhdmUgbm8gYW55IHZhbHVlLiBBcyBmb3IgYmFzaWMgaW50ZXIt c3VibmV0IGxheWVyIDMgY29tbXVuaWNhdGlvbiBhbmQgaW50cmEtc3VibmV0IGxheWVyIDIgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIE5WRXMsIGN1cnJlbnQgTlZHUkUsIFZYTEFOIGFuZCBMSVNQIGhh dmUgYWxyZWFkeSBzdXBwb3J0ZWQsIE5WR1JFLFZYTEFOLExJU1AgYW5kIFZYTEFOLUdQRSBjYW4g YmUgaHlicmlkIHVzZWQgdG8gZm9ybSBhIE5WTzMgbmV0d29yayBpZiBvbmx5IGJhc2ljIGxheWVy IDMgYW5kIGxheWVyIDIgZm9yd2FyZGluZyBwcm9jZXNzIGV4aXN0cy4gQXMgZm9yIHNvbWUgZXh0 cmEgZnVuY3Rpb25zIG9mIE9BTSwgc2VydmljZSBjaGFpbmluZyxhbmQgZXRjLCAgb25seSBWWExB Ti1HUEUgY2FuIHN1cHBvcnQsIHB1cmUgVlhMQU4tR1BFIG5ldHdvcmsgc2hvdWxkIGJlIHVzZWQg aW4gdGhlc2UgY2FzZXMuDQpUaGFua3MNCndlaWd1bw0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGlubyBGYXJpbmFjY2kgW2ZhcmluYWNjaUBn bWFpbC5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCMjjI1SAyMToxNQ0KytW8/sjLOiBIYW93ZWln dW8NCrOty806IFRvbSBIZXJiZXJ0OyBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1Ag bWFpbGluZyBsaXN0IGxpc3QNCtb3zOI6IFJlOiC08Li0OiBbbnZvM10gQ29tbWVudHMgb24gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQoNCj4gT24g SnVsIDI4LCAyMDE0LCBhdCA3OjI0IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29t PiB3cm90ZToNCj4NCj4gQWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaSBhbHNvIGFncmVl IHdpdGggRGluby4gVlhMQU4tR1BFIHNob3VsZCBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFk ZXIgYW5kIHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCBwb3J0LCB0aGUgZGF0 YSBmb3JtYXQgZG9uJ3QgbmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgg VlhMQU4gaGVhZGVyLiBJDQoNCkkgd2FudCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgc3VwcG9ydGlu ZyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIHZlcnkgaW1wb3J0YW50IHNpbmNlIFZYTEFOLXBv cnQtNDc4OSBpcyBzdXBwb3J0ZWQgaW4gdmFyaW91cyBjaGlwcyBhbHJlYWR5Lg0KDQpEaW5v From nobody Mon Jul 28 09:23:30 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE41A0310 for ; Mon, 28 Jul 2014 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4dsPS2yZ_qB for ; Mon, 28 Jul 2014 08:08:32 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371DE1B2890 for ; Mon, 28 Jul 2014 08:08:32 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so3793213igb.8 for ; Mon, 28 Jul 2014 08:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EVuE9LFU3uq299dzh3R8IvW6z6Rx8gpwx/RvpJqayBo=; b=JLVUsl2RkT3orXbYkqhmjtTSK42QsrCmujQlHsO+hJUqQyY2wPI6aru1lx6JrlE3DR tUcmfuanZFFKbof+HQhYVRb9GzjazEYFpRFtK30bXc6UQYMrZSvmBC3Bo/gfOC4aau0B vsgZYrRaNJeQp+2wf4YI51INrUbXUSWVhwvL8OiVkDnwJjwsANE1Ebg3IxFUTIAuNM0i VsulRD4JHDCJvPDCl+8lv93cvYetTrrtZlNvJWsueDQwb5dRu0OrHDrpk3gRgKUR5Wsm Afc12mv/xhMQqmUvzZAURnJfkeUcJW6ga89+X0C+JcF+EHgHPU6M888PGC2ZY3IYeKr6 yCUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EVuE9LFU3uq299dzh3R8IvW6z6Rx8gpwx/RvpJqayBo=; b=E7MufKhXd5EnqJue+H8EWJDKbw8j0U8pyVkkIGu+Ir7URXuJOlXPqNkGdRvJFCFE9n PHClduZVal1Vk4mAoqTHJA8qQ416y/s04o1tibWaWxhhnuU8vjlke2ONZIzNGDGfEqfM w49LHM5CTA+bZU6Eqd9aqPXNUrCUgOifxOLlb7irD7Cege5pGuVSRhVNZrl/+gfLh9tU 9EKmmCAkfQoKTGJfrnMXqqMatEG6atNfu8QLDdnzWG/NVCcYK1KWoIYhSIAlPTULdusk i5Iy698jkx8cm9PqGN88iOGzOw0Liro0oHacuaWZ5ZBYgf9CBfOuccdJ6fqxCWez74Sf VyKQ== X-Gm-Message-State: ALoCoQn0X3k/iTbbxGnceykQ/813jLVnGIat0bXd+dLV/9whPF+0QRHceQHwb1/6y+LzEolAqW4V MIME-Version: 1.0 X-Received: by 10.42.93.84 with SMTP id w20mr44736139icm.49.1406560111533; Mon, 28 Jul 2014 08:08:31 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Mon, 28 Jul 2014 08:08:31 -0700 (PDT) In-Reply-To: <20140727235848276183.21b2fe35@sniff.de> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> Date: Mon, 28 Jul 2014 08:08:31 -0700 Message-ID: From: Tom Herbert To: Marc Binderberger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Bsct_lEhRAttYbCyE0kMxi51bZk X-Mailman-Approved-At: Mon, 28 Jul 2014 09:23:20 -0700 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:08:34 -0000 >> Allowing the reserved bits in the header to be ignored on receive >> limits the usefulness in that new bits that are defined can only be >> advisory and not fundamentally change interpretation of the packet. > > I agree with your statement in the 2nd half but not your opinion about th= e > usefulness. Don't see a problem here, LISP is a good example how ignoring > unknown flags works well. > How so? Adding protocol field to LISP-gpe has the same backwards compatibility problem as VXLAN-gpe, but is resolving it in a different way. The addition of the P-bit relies on some (presumably) out of band mechanism to ensure protocol compatibility. From the LISP-gpe draft: "A LISP-gpe router MUST not encapsulate non-IP packets to a LISP router. A method for determining the capabilities of a LISP router (gpe or "legacy") is out of the scope of this draft." Thanks, Tom > > Regards, Marc > > > > On Sun, 27 Jul 2014 17:28:01 -0700, Tom Herbert wrote: >> On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wr= ote: >>>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and >>>> requires the assignment of a new UDP port. The fact that the VXLAN-G= PE >>>> header closely resembles VXLAN may be convenient for implementers, but >>>> this protocol by definition is not backward compatible with VXLAN. >>> >>> If you do that then it will be harder for VXLAN-GPE systems to >>> interoperate with a VXLAN systems. Because a VXLAN-GPE system will need= to >>> open and maintain 2 UDP sockets. And an implementaiton will have to be >>> careful to not set the P-bit for the VXLAN socket or clear the P-bit fo= r >>> VXLAN-GPE socket. This is all completely unnecessary and one way or the >>> other should be used. >>> >> I am not sure what you are suggesting. AFAICT there is no backwards >> compatible means to to add the protocol field to VXLAN which is the >> motivation for the new UDP port, which in turn implies a new protocol >> (which also implies an opportunity to add a more general set of >> protocol features like version number and options extensions which are >> also not backwards compatible). Maybe it's possible to break >> compatibility within the protocol and assume that out of band >> mechanisms could negotiate use of P-bit to compensate, but I assume >> there's already quite a bit of VXLAN deployment so that seems pretty >> shaky robustness-wise to me. >> >> It's not just adding the protocol field that would be an issue, even >> adding the OAM bit to VXLAN would be problematic. Per VXLAN spec >> unspecified flag bits are ignored on receive, so if the OAM bit were >> subsequently defined in VXLAN it will be ignored by existing >> implementations and these packets will be processed normally-- this >> seems to be incompatible with the proposed VXLAN-gpe requirement that >> "When the O bit is set to 1, the packet is an OAM packet and OAM >> processing MUST occur." (btw 'OAM processing' is awfully ambiguous to >> be a MUST here IMO). >> >> Allowing the reserved bits in the header to be ignored on receive >> limits the usefulness in that new bits that are defined can only be >> advisory and not fundamentally change interpretation of the packet. >> Had the requirement in VXLAN been that packets with unknown bits set >> be dropped, then adding P-bit and O-bit could have been done with >> backwards compatibility. This might be a reasonable requirement to >> consider if new protocol (i.e. new port number) is undertaken. >> >> Thanks, >> Tom >> >>> And if *it was agreed* on to use different UDP port numbers (like the w= ay >>> LISP did it for L2 versus L3 packet encapsulation), we wouldn't need th= e >>> P-bit at all. But there was push back (by somebody) to not allocate >>> another port for VXLAN, so the demux was forced to be in the VXLAN head= er. >>> >>> And is also the reason this baggage is being carried over the LISP when= it >>> really isn't needed. >>> >>>> 3. True, the =E2=80=98P=E2=80=99 bit is not needed for backward compat= ibility, but I=E2=80=99m >>>> not against it if there is value to make it consistent with the LISP-G= PE >>>> header. >>> >>> There is no incremental benefit to use the P-bit for LISP. We had a >>> solution but because of the requirement to have no new port for VXLAN, >>> LISP is affected. >>> >>> Just another example how the working group is putting effort into thing= s >>> that creates more work but no benefit. Don't get me wrong, the cisco gu= ys >>> did this (the VXLAN and LISP same position for P-bit) for consistency, = and >>> they should be applauded for that. But if VXLAN could have another port >>> number assigned for "other protocols", maybe the VXLAN-GPE would look s= o >>> much different. >>> >>> Something to think about as the working group now has new productivity >>> mentality. >>> >>> Dino >>> >>> _______________________________________________ >>> 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 nobody Mon Jul 28 09:25:55 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC41A037C for ; Mon, 28 Jul 2014 09:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsoWOjZ6h22P for ; Mon, 28 Jul 2014 09:25:49 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7ABC1A035C for ; Mon, 28 Jul 2014 09:25:48 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id uq10so3881742igb.11 for ; Mon, 28 Jul 2014 09:25:48 -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=wY9rJZArNVNabgD6Am31vfdQcNru9ti/T1QmGpc8OnY=; b=ZluBOXg8DS1GCczAh6iyVZQ3dqETJ6ezuP3bdAjtkwFt42h7za7SVuY1X9/3TmQID+ Nr9RlbE1eTXsBKxE5a0mr4vAPH3Jl83JIfc0OydlD0QlT8SaSYCtfpeGtd2C3WFv8CEs Q3uXTSCdLewljRk8vM2/ubL4vIZbAwP9D5KKtozqDB0YRS06P0xyIfqwIW4wj/8T0XG+ F+rQxGktdTPyV7urG6AgLafPap1uR1v2oRGtyFXwV/nnm5U4FF8iN4PIo5DrlxmZ+awu L1bGVeIf1Er0dzaRKxgCDKAhd2y3qJ/iO3xxH1WeoGCL8Ks4ZN/bR+KiCVErPbs4gdCD rfRg== X-Received: by 10.50.4.9 with SMTP id g9mr33616907igg.42.1406564748206; Mon, 28 Jul 2014 09:25:48 -0700 (PDT) Received: from [172.19.131.148] ([12.130.116.26]) by mx.google.com with ESMTPSA id l5sm28121536ige.6.2014.07.28.09.25.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 09:25:47 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jul 2014 09:24:30 -0700 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/thCzf8DB6fhglsDUM5iBxzw0-8Q Subject: [lisp] Comments to draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 16:25:53 -0000 See my comments inline. The draft text comes first and is indented and = my comments follow. I included only draft text that I have comments on. = Thanks. > 1. Prefatory Note This section should be titled "Introduction". > {{Suggestion by editors: Remove all the sections before "LISP > Overview" and write a straight-to-the-point introduction}} Agree. > {{Suggestion by editors: The draft should focus on describing the > LISP architecture and avoid comparing loc/id split architectures = with > other approaches}} Agree. > This document is the first of a pair which, together, form what one > would think of as the 'architecture document' for LISP (the > 'Location-Identity Separation Protocol'). Much of what would If you do a good job, I am not sure you really need a pair of documents. > normally be in an architecture document (e.g. the architectural > design principles used in LISP, and the design considerations = behind > various components and aspects of the LISP system) is in the second > document, the 'Architectural Perspective on LISP' document. > [I-D.ietf-lisp-perspective] What is the plan for this document? > This 'Architectural Introduction' document is primarily intended = for > those who are unfamiliar with LISP, and want to start learning = about > it. It is intended primarily for those working on LISP, but those > working with LISP, and more generally anyone who wants to know more > about LISP, may also find this document useful. Agree on the intent. > This document is intended to both be easy to follow and it is > structured as a series of phases, each covering the entire system, > but with ever-increasing detail. Reading only the first part of = the > document will give a good high-level view of the system; reading = the > complete document should provide a fairly detailed understanding of > the entire system. Agree. > People who just want to get an idea of how LISP works might only = read > the first part; they can stop reading either just before, or just > after Section 9. People who are going to go on and read the = protocol > specifications (perhaps to implement LISP) should read the entire > document. >=20 > This document is a descriptive document, not a protocol > specification. Should it differ in any detail from any of the LISP > protocol specification documents, they take precedence for the = actual > operation of the protocol. Make sure we capture this in the next rev. >=20 > 3. Initial Glossary I think you should refer to the various documents for a glossary of = terms. This was also Fabio's comment. I also think this document should list the other RFCs that are related = to the design and then a list of Internet Drafts that might be added to = the working group charters in the future. A one-stop shop to finding all = documents in one place is really very reader friendly. > 5. Deployment Philosophy >=20 > {{Suggestion by editors: Remove the entire section, it can be > summarized by the last paragraph. Furthermore the arguments used = in > this sections are hard to follow since LISP has not been described > yet.}} Agree. > 5.1. Economics >=20 > {{Suggestion by editors: Remove this section, this has not been > discussed by the WG}} Agree. >=20 > 5.2. Maximize Re-use of Existing Mechanism >=20 > {{Suggestion by editors: Remove/Summarize the entire section, the > arguments used in this section are hard to follow since LISP has = not > been described yet.}} Agree. > 6.1. Basic Approach >=20 > {{Suggestion by editors: Merge this section with the previous one > (LISP Overview)}} Agree. > 6.2. Basic Functionality >=20 > {{Suggestion by editors: Rewrite this section: It is using non- > standard terminology to refer to standard LISP concepts ('enhance' > instead of encapsulate) It is using subjective terms (e.g., 'near' > the source) It is missing key LISP aspects such as that RLOC = packets > are forwarded in the RLOC space }} Agree. > 6.5. Security in LISP >=20 > {{Suggestion by editors: Rewrite this section: (first 3 paragraphs) > It contains a general discussion as well as strong statements that > are not supported by any WG document. (last 3 paragraphs) It > enumerates the security mechanisms specified in LISP but does not > describe them.}} Agree. You should talk about 3 types of security: (1) Data-Plane security and what the current goals are. (2) Control-Plane security is what LISP-SEC solves. (3) Mapping database security where one example is LISP-DDT-SEC. >=20 > 7. Initial Applications >=20 > {{Suggested by editors: Move this section after section 8, the > applications should not be described before LISP has been fully > described. Agree. > {{Suggested by Noel: Reorder the whole section in popularity = order?}} Describe the architecture and protocol first, and then describe the = use-cases so they can refer to terms and concepts previously mentioned. >=20 > 7.1. Provider Independence >=20 > Provider independence (i.e. the ability to easily change one's > Internet Service Provider) is a good example of the utility of > separating location and identity. Since LISP has evolved so much, it turns out to be more of a mobility = and overlay solution than a solution to solving the routing table = problem, even though it does when deployed. So when discussing and = describing EIDs and RLOCs, just note at that time that EIDs are provider = independent and RLOCs are provider dependent. >=20 > 7.2. Multi-Homing >=20 > {{Suggested by editors: This section should be extended, it is > unclear the benefits that LISP brings to multihoming (.e.g, traffic > engineering, decoupled multihoming from the data-plane). I think when you talk about RLOCs, you should indicate there is an = RLOC-set that can contain multiple RLOC addresses. That is the ideal = time to say you get multihoming out of LISP. > 7.3. Traffic Engineering >=20 > {{Suggestion by editors: Merge this section with the previous one, = TE > is not practical without multihoming}} Well I think when you define and talk about ITRs and ETRs, and their = interworking counter-parts PITRs and PETRs, that the mention of RTRs is = a good place to introduce the concept. Then you can say how RTRs can do = TE, even if they are reached via multiple RLOCs in an RLOC-set. >=20 > 7.4. Routing >=20 > {{Suggestion by editors: Remove this section, LISP is not a routing > protocol.}} Agree 100%. LISP is an overlay and it depends on the routing system that = it runs over. Nothing else should be stated. How LISP uses the underlay = to get more efficient paths is what could be listed in the use-case = section when RLOC selection, Segment Routing, and OAM may be mentioned. > 7.5. Mobility >=20 > {{Suggestion by editors: Remove this section, mobility is not in > charter.}} Mobility from a host perspective is not in the charter. And putting = LISP-MN in hosts is not in the charter but general IP address (i.e. EID = mobility is). We have a considerable amount of text in RFC 6830 that = talks about mobility. And furthermore, since multi-homing is in the = charter, when one changes an RLOC address to connect to a new provider, = that is, in effect, a mobility event. > 7.7. Virtual Private Networks >=20 > {{Suggestion by editors: Remove this section, not covered by any WG > document}} Put it in a use-case section that briefly describes it. And when you = describe EIDs, indicate that an EID can be multiple-tuple hence a {IID, = EID} is used for the VPN use-case. > 7.8. Local Uses >=20 > {{Suggestion by editors: Remove this section. The section contains = a > general discussion about the applicability of LISP in intra-domain > scenarios, however it does not describe any specific application.}} Agree. >=20 > {{Preceeding paragraphs should probably get moved up into VPN > section?}} Yes, agree. > 8. Major Functional Subsystems >=20 > {{Suggestion by editors: This section should appear before since it > describes key aspects of LISP (e.g., LISP decoupled control and = data- > plane).}} Agree. > 8.1. Data Plane - xTRs Overview >=20 > {{Suggestion by editors: Extend this section, it misses key LISP > data-plane aspects, such as the map-cache.}} Yes, agree. > 8.1.1. Mapping Cache Performance >=20 > {{Suggestion by editors: Push this section further in the document, > the cache performance is not a "Major LISP subsystem"}} Agree. > 8.2. Control Plane - Mapping System Overview >=20 > {{Suggestion by editors: Rewrite: Replace EID block terminology > (along with its description) with the very common term "prefix". > Describe Map-Request/Map-Reply LISP signaling messages.}} Agree. > 8.2.1. Mapping System Organization >=20 > {{Suggestion by editors: Rewrite: Describe key Mapping System > components: Map-Server/Map-Resolver}} And describe how the mapping system is modular and any mapping database = transport system can be plugged in. And then describe the various ones = we considered in the past. To list them: DNS, DHTs, ALT, Emacs, Nerd, = and DDT. It gives the reader the knowledge that we had many approaches = to this. > 8.2.2. Interface to the Mapping System >=20 > {{Suggestion by editors: has been rewritten: This section should > appear earlier since it describes key LISP components (Map-Request/ > Map-Reply/Map-Server/Map-Resolver}} Agree. > 8.2.3. Indexing Sub-system >=20 > {{suggestion by editor: rename the section to "DDT"}} We have to be careful here because ALT is in RFC stages and DDT is not = even a working group document yet. We know the future is DDT, but the = future will also have other/newer approaches as well. > 9.1. An Ordinary Packet's Processing >=20 > {{Suggestion by editors: This section should be earlier in the > document structure, examples are important -particularly for > engineers- to explain how systems work}} Yes, I have done 100s of LISP presentations and describing the packet = flow first, assuming the map-cache is populated, is must easier for = people to understand. Then next, present what happens when the map-cache = is not populated, and then describe the interface to the mapping system, = and then how the mapping transport system connects map-resolvers and = map-servers together. > 9.2. A Mapping Cache Miss >=20 > {{Suggestion by editors: (same as previous section)}} Yes, my comment from above applies here too. > If a host sends a packet, and it gets to the ITR, and the ITR > determines that it does not yet have a mapping cache entry which > covers that destination EID, then additional processing ensues; it > has to look up the mapping in the mapping system (as previously > described in Section 6.2). >=20 > The overall processing is shown below, in Figure 2: >=20 > ----- ----- > | | 3 | | > Map Resolver | | -------> | | Map Server > | | | | > ----- ----- > ^ | > Key: | | > | | > -- =3D Control | | > =3D=3D =3D Data | | > 2 | 5 | 4 > | --- | > Host A | / \ | Host B > | |_ \ V > ----- ----- \ ----- ----- > | | 1 | | 6 | | 7 | | > | | =3D=3D=3D=3D=3D> | ITR | =3D=3D=3D=3D=3D=3D=3D> | ETR | = =3D=3D=3D=3D=3D> | | > | | | | | | | | > ----- ----- ----- ----- >=20 > Figure 2: Packet flow with missing mapping I like this picture (came from UPC originally anyways). This should be = very close to up front in the document. A picture says a 1000 words. > 10. Part II >=20 > {{comment from editors: is that the role of an introductory = document > to enter in such level of details and discuss (mostly) all fields = of > the protocol? }} It absolutely should not be. If we do this, the document set will be = inconsistent and in contradiction. This document should not repeat any = details that are in other documents. Especially since those documents = are very more detailed than what this intro document should be. > 11. Design Approach >=20 > {{Suggestion by editors: Remove this section, it does not describe/ > discuss anything relevant, it is only providing a reference to > another non-WG document.}} Agre. > 12. xTRs >=20 > As mentioned above (in Section 8.1), xTRs are the essential LISP = data > plane elements. This section explores some advanced topics related > to xTRs. >=20 > {{Suggestion by editors: remove next paragraph, brings nothing)}} >=20 > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that traceroute works when xTRs are involved. We need to colapse the coarse information that is here into the previous = section. No details. One document that flows well and is short is what = will win. Otherwise, this will be just another IETF document people = can't read and digest. > 12.3. Header Control Channel >=20 > {{Suggestion by editors: Rewrite this section to improve = readability, > use standard terminology (e.g., Cache Coherence/Reachability = instead > of "Header Control Channel"). Split the mechanisms depending on = its > goal (cache coherence/reachability) and describe them under the = same > context.}} Agree. > 12.3.3. Instances >=20 > {{Suggestion by editors: Move and extend this section: - Instance = ID > is not a cache-coherence/reachability algorithm. Describe where = and > what is the Instance ID field Explain its applications}} Agree. > 12.4. Probing >=20 > RLOC-Probing is a mechanism method that an ITR can use to determine > with that an ETR is up and reachable from the ITR. As a side- > benefit, it gives RTT estimates. >=20 > To probe the reachability of an RLOC, an ITR sends a specially = marked > Map-Request directly to the ETR it wishes information about; that = ETR > sends back a specially marked Map-Reply. A Map-Request message and = a > Map-Reply message are used, rather than a special probing control- > message pair, because as a side-benefit the ITR can discover if the > mapping has been updated since it cached it. >=20 > {{Suggestion from editors: remove the following sentence as it is = not > motivated by strong arguments}} The probing mechanism is rather > heavy-weight and expensive (compared to mechanisms like the Echo- > Nonce), since it costs a control message from each side, so it = should > only be used sparingly. Agree. > 12.5. Mapping Lifetimes and Timeouts >=20 > {{Suggestion by editors: Remove this section, TTL is a simple well- > known concept, we suggest to include a sentence (and hence remove > this section) in the control-plane section stating that mappings > include a TTL. Agree. > 12.6. Mapping Gleaning in ETRs >=20 > {{Suggestion by editors: Remove this section, gleaning is = discouraged > since it rises many security concerns.}} Agree 100%. > 12.8. Security of Mapping Lookups >=20 > {{Suggestion from editors: would remove all what is related to > security and instead put a small summary in the security section = and > reference the threats document}} Since security is work in progress (and the documents that are stable = have not really been tested throuoghly in practice) the description of = security in LISP must be high-level. > 13. The Mapping System >=20 > {{Suggestion by editors: This section is somewhat redundant with > respect to section 8.2, we suggest to move this section to Part I > since it provides some missing details.}} Agree. > 13.1.1. Map-Request Messages >=20 > {{Suggestion from editors: should come much earlier as it is an > essential message in LISP}} Agree and the only aspect of Map-Request, Map-Register, Map-Reply, = Map-Referral, and Map-Notify messages should be what is being conveyed = and to where. The details of encoding is way too detailed. The goal of this document is be be able to change details and add = use-cases to LISP without having to change the document. We should at = least strive for that if reality doesn't play it out that way. > 13.1.2. Map-Reply Messages >=20 > {{Suggestion from editors: should come much earlier as it is an > essential message in LISP}} Yes, same comment as right above. > 13.1.3. Map-Register and Map-Notify Messages >=20 > {{Suggestion by editors: As noted by the author add a paragraph > describing how a xTR de-registers an EID-to-RLOC mapping.}} Yes! > {{Suggestion by editors: add a small paragraph to explain what Map- > Registers are used for}} Yes, same comment as right above. I think you can summarizing all = control-plane messages in one section. One section, with one paragraph = per message type. >=20 > 13.2. The DDT Indexing Sub-system >=20 > {{Suggestion from the editors: this section does not add any > fundamental value to the DDT overview section, propose to remove it > to only keep the overview; too much details that should not appear = in > an intro document}} Agree. > 13.3. Reliability via Replication >=20 > {{Suggestion by editors: Remove this section, describes operational > practices/policies of the DDT infrastructure, this is beyond the > scope of this document.}} Agree. > 13.4. Security of the DDT Indexing Sub-system >=20 > {{Suggestion by editors: Remove this section, provides unnecessary > details of DDT.}} Agree. > 13.5. Extended Capabilities >=20 > {{Suggestion by editors: Remove this section, not discussed in any = WG > document.}} Agree. > 13.6. Performance of the Mapping System This is an intro document, not an analysis document. This section should = be removed IMO. > 14. Multicast Support in LISP >=20 > {{Suggestion by editors: Rewrite this section, it provides too many > details. Reduce it to a brief description of LISP Multicast}} Agree 100%. It should simply be stated that multicast packets can be = encapsulated in multicast and unicast RLOCs with any combination of = underlay signaling, overlay signaling, or no signaling. And that = Replication Engineering is necessary to optmize paths and minimize = head-end replication in the unicast RLOC case. > 14.2. Initial Multicast Support in LISP >=20 > {{Suggestion by editors: remove this paragraph}} Ack. > 15. Deployment Issues and Mechanisms >=20 > {{Suggestion by editors: Remove this section, provides unnecessary > details. Add a reference to the deployment RFC.}} Agree. > 15.2.1. Proxy LISP Routers >=20 > {{Suggestion by editors: Move this section to Part I. PxTRs are an > important aspect of LISP and as such, should be described before. > Furthermore simplify it, it currently contains too many details = plus > an additional discussion on the impact of PITR that is out of the > scope of the document.}} Agree. Where you first introduce the concept of PITRs and PETRs that is = where you mention a little more about interworking. > 15.2.2. LISP-NAT >=20 > {{Suggestion by editors: Remove this section, LISP-NAT is not a WG > document neither an inter-networking mechanisms.}} I agree. It is a suggestion in the interworking spec but the deployment = spec does not recommend to use it so PxTRs is what we should focus on. > 15.3. Use Through NAT Devices >=20 > {{Suggestion by editors: Remove this section, LISP-NAT is not a WG > document neither an inter-networking mechanisms.}} This is meant to describe NAT-traversal not LISP-NAT for interworking. I = think the problem is important to solve but just explain what I said = above about how RLOCs can be private or public and the Map-Servers can = teach the xTRs what their global RLOC addresses are. > 15.4. LISP and Core Internet Routing >=20 > {{Suggestion by editors: Remove this section, this is already > explained in lisp-deployment}} Agree. > 16. Fault Discovery/Handling >=20 > {{Suggestion by editors: Remove this section, although this section > helps understanding how many of the LISP mechanisms work > (particularly the ones described in section 12) it provides an > unnecessary level of (operational) detail. This level of > understanding should be achieved reading the main LISP spec. }} Agree. > 16.3. Erroneous Mappings >=20 > {{Suggestion by editors: this section brings nothing, remove it}} Agree. >=20 > 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. >=20 > 16.4. Verifying ETR Liveness >=20 > The ITR, like all packet switches, needs to detect, and react, when > its neighbour ceases operation. As LISP traffic is effectively > always uni-directional (from ITR to ETR), this could be somewhat > problematic. >=20 > Solving a related problem, "neighbour ETR" "reachability" below) > subsumes handling this fault mode, however. >=20 > {{Suggestion by editors: remove next paragraph }} Put reachability in one section when you talk about overlay/underlay = interaction. > 17. Acknowledgments >=20 > This document was initiated by Noel Chiappa, and much of the core > philosophy came from him. We acknowledge the important = contributions > he has made to this work and thank him for his past efforts. This section should also thank the RRG from the IRTF as well as the LISP = WG from the IETF. > Appendix A. Glossary/Definition of Terms >=20 > {{Suggestion by editors: remove and use those from RFCs instead }} Agree. > Appendix B. Other Appendices >=20 > B.1. A Brief History of Location/Identity Separation This section should be removed or shortened quite a bit. And it should = be part of the intro if shortened. But it needs to be short, if added to = the top of the document. > B.2. A Brief History of the LISP Project >=20 > {{Suggestion by editors: remove that makes no sense in this = document > }} Agree. This can be moved to the LISP wiki. > B.4. The ALT Mapping Indexing Sub-system This should not be in an appendix. It should be in the section that = describes the indexing system in general and give some examples of a few = of them. Pointers to drafts are imperative IMO. > B.5. Early NAT Support I think the description of NAT-traversal should be integrated with the = description of RLOCs. And just note how LISP can work behind NATs and = how an xTR will distinguish a private RLOC from a public RLOC. That's all for now. Looking forward to the next revision. Thanks, Dino From nobody Mon Jul 28 10:22:16 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9294C1A0326; Mon, 28 Jul 2014 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPPQwk76ve2u; Mon, 28 Jul 2014 10:22:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E818F1A04B1; Mon, 28 Jul 2014 10:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=424; q=dns/txt; s=iport; t=1406568123; x=1407777723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8tplnHoalXoOJL5H3k/MOiEDZRFhwXtqz+fRAu6Ua1I=; b=WoeE/uzscFPSoej2o6Bub0cs7Sb9zPQtnZI79H24kbHmL6gKt1xiTmQW Z3uPNjqHbmrALsJFiuXdv4GW8+L2N/jQ+qrnMVIuU0nERZuaEAytT984O xxhRku1BJiy5wljo5Mju2Lqe/ofhi8/8rPKbNq1pYsrOuXhAZZY5TCuMr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANeF1lOtJA2G/2dsb2JhbABZgw5SVwTMCodFAYEQFneEBAEBAwE6MgoDEAIBCDYQIRElAgQOBYguAwkIDbcZDYcHF40fgXozB4MvgRsBBJlHggWBUoxXhiODSWyBRQ X-IronPort-AV: E=Sophos;i="5.01,750,1400025600"; d="scan'208";a="343378660" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2014 17:22:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6SHM2Rj024953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 17:22:02 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 12:22:01 -0500 From: "Darrel Lewis (darlewis)" To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqohxFDuESdVPfU+MWLGrMK03OQ== Date: Mon, 28 Jul 2014 17:22:01 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> In-Reply-To: <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.182] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/UwW1wJjyljRe7ounvKGmoCblFlY Cc: LISP mailing list list , "nvo3@ietf.org" , David Melman , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 17:22:09 -0000 On Jul 28, 2014, at 3:14 AM, Dino Farinacci wrote: >> The point Dino makes is (I think): is there really a gain to "re-invent"= =20 >> VxLAN and LISP data encapsulation? And it might be actually easier to=20 >> implement and test separate encodings instead of the more complex combin= ed=20 >> header in VxLAN-gpe. >=20 > Exactly.=20 And the authors believe there is value. -Darrel= From nobody Mon Jul 28 11:39:45 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CAA1A0097; Mon, 28 Jul 2014 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLBs3HdeoipO; Mon, 28 Jul 2014 11:39:42 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0241A03C2; Mon, 28 Jul 2014 11:39:42 -0700 (PDT) Received: by door.sniff.de (Postfix, from userid 1000) id 3A03D2AA11; Mon, 28 Jul 2014 18:39:40 +0000 (GMT) Date: Mon, 28 Jul 2014 18:39:40 +0000 From: Marc Binderberger To: "Darrel Lewis (darlewis)" Message-ID: <20140728183939.A25626@door.sniff.de> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <3CAE1D58-3277-4B8E-A4AF-F52CC81192D6@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from darlewis@cisco.com on Mon, Jul 28, 2014 at 05:22:01PM +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/DFY-bn3rKYqP18Hr7c15zyCWj6c Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:39:43 -0000 Hello Darrel, > And the authors believe there is value. otherwise you wouldn't have written it down ;-) That's what this discussion is (also) about: learning what are the pros and cons and how to weight them. Regards, Marc From nobody Mon Jul 28 13:29:12 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7880A1A0191 for ; Mon, 28 Jul 2014 13:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrUlpWvTYRnv for ; Mon, 28 Jul 2014 13:28:50 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C34B1A00EB for

--bcaec51a855800d03304ff46c9cd-- From nobody Mon Jul 28 14:23:23 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DBF1A02A0 for ; Mon, 28 Jul 2014 14:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXai8R0qGecV for ; Mon, 28 Jul 2014 14:23:17 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9A31A01E2 for ; Mon, 28 Jul 2014 14:23:16 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so7368431iec.36 for ; Mon, 28 Jul 2014 14:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=DQGDui4PD83MFxihya5jPQn9SgpbEfXCiRDLiVTNAAs=; b=Tvp2qLpYkdF68VFF4aL7NKsstdfxFQfkuIOD0OS2QTQt78zsJE5mOd/W+OSW3QbMia yB4xu789vivxKq4P1/XbDIHwz42AumGVH3jzUhzWToI7V5KhYUY3zVJW0NipfthPP3XN zXa/G483+2216dh/gXH7i+3BgU3IzupoOJXqdKcC26Dx1udPWFExFhVu80AV+KOeCyWd gNC0kNf5CXJUeRcOTfB7KsBsO/zi1dDrt9jauXoJo4J6lnd/DZwbWJjHIG2gZDYDkeUU VWMZG+9jLT3ZY4mkCi2JuXH++0txpqaHeJpqlHYaGHZgk1CWQAUAKuLhqRxbJOr9/cev Jblg== MIME-Version: 1.0 X-Received: by 10.50.114.38 with SMTP id jd6mr35174752igb.25.1406582596309; Mon, 28 Jul 2014 14:23:16 -0700 (PDT) Received: by 10.107.13.5 with HTTP; Mon, 28 Jul 2014 14:23:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Jul 2014 23:23:16 +0200 Message-ID: From: Albert Cabellos To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/6SpdYSPIJ0HlbEjxqHiqOeoViXw Cc: LISP mailing list list Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:23:21 -0000 Hi Dino I=C2=B4ve noted all the comments for which we both agree, please see my comments below: On Mon, Jul 28, 2014 at 6:24 PM, Dino Farinacci wrote= : > See my comments inline. The draft text comes first and is indented and my= comments follow. I included only draft text that I have comments on. Thank= s. > >> 1. Prefatory Note > [snip] > >> normally be in an architecture document (e.g. the architectural >> design principles used in LISP, and the design considerations behind >> various components and aspects of the LISP system) is in the second >> document, the 'Architectural Perspective on LISP' document. >> [I-D.ietf-lisp-perspective] > > What is the plan for this document? This is a non-WG document and I suggest not to cite it. [snip] > >> 7.3. Traffic Engineering >> >> {{Suggestion by editors: Merge this section with the previous one, TE >> is not practical without multihoming}} > > Well I think when you define and talk about ITRs and ETRs, and their inte= rworking counter-parts PITRs and PETRs, that the mention of RTRs is a good = place to introduce the concept. Then you can say how RTRs can do TE, even i= f they are reached via multiple RLOCs in an RLOC-set. lisp-te is not part of the WG and I suggest to stick to WG items. We can include them in the use-cases appendix. > >> >> 7.4. Routing >> >> {{Suggestion by editors: Remove this section, LISP is not a routing >> protocol.}} > > Agree 100%. LISP is an overlay and it depends on the routing system that = it runs over. Nothing else should be stated. How LISP uses the underlay to = get more efficient paths is what could be listed in the use-case section wh= en RLOC selection, Segment Routing, and OAM may be mentioned. Ok, I also think that it makes sense to add them in the use-cases. > >> 7.5. Mobility >> >> {{Suggestion by editors: Remove this section, mobility is not in >> charter.}} > > Mobility from a host perspective is not in the charter. And putting LISP-= MN in hosts is not in the charter but general IP address (i.e. EID mobility= is). We have a considerable amount of text in RFC 6830 that talks about mo= bility. And furthermore, since multi-homing is in the charter, when one cha= nges an RLOC address to connect to a new provider, that is, in effect, a m= obility event. Good point! We=C2=B4ll indeed mention it. [snip] > >> 8.2.3. Indexing Sub-system >> >> {{suggestion by editor: rename the section to "DDT"}} > > We have to be careful here because ALT is in RFC stages and DDT is not ev= en a working group document yet. We know the future is DDT, but the future = will also have other/newer approaches as well. > DDT is an expired WG document (https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/). [snip] > >> 15.2.2. LISP-NAT >> >> {{Suggestion by editors: Remove this section, LISP-NAT is not a WG >> document neither an inter-networking mechanisms.}} > > I agree. It is a suggestion in the interworking spec but the deployment s= pec does not recommend to use it so PxTRs is what we should focus on. > >> 15.3. Use Through NAT Devices >> >> {{Suggestion by editors: Remove this section, LISP-NAT is not a WG >> document neither an inter-networking mechanisms.}} > > This is meant to describe NAT-traversal not LISP-NAT for interworking. I = think the problem is important to solve but just explain what I said above = about how RLOCs can be private or public and the Map-Servers can teach the = xTRs what their global RLOC addresses are. You mean section 8.4 of RFC6830? From nobody Mon Jul 28 14:28:12 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7381E1A02F7 for ; Mon, 28 Jul 2014 14:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h093ShfdrdVA for ; Mon, 28 Jul 2014 14:28:08 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAD51A02D0 for ; Mon, 28 Jul 2014 14:28:08 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so10478980pdj.7 for ; Mon, 28 Jul 2014 14:28:08 -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=3YrcuZ9u/3KrHnurA05bHEj0uNbdOO/VDFvmgROcxKM=; b=wH6xE2RwMNp/zpioLz2saqjvitEf4/xpdEzd1K5FxxmyFVS9RmtdoWgKJMb0qkn/rb 7XU94gMPX8bP2GsbIVr+oOmKhTz8JBZV/sVQyaqCBvmGtL2allA8wpyHng6Fyo1nSjmi Mj6TRkpSggNqDKo/tjiLJHX4IV43Rit6QrNnMCbwuRSdO23LGBUjYmynZFRJv20SZLng mhyMzvLkQVWWLV7qdhwsqP2eCGGw6c6f2dkedpPD86/lJaB/gGbWj1zLeh/n2aGpLMby /rzzR9sOVlvIvLqkBMEX6pQ4leq9parPrcZgh04WftL6ITqnzQ/iaQdQnqcUmw9K5VFM 3cMg== X-Received: by 10.66.174.17 with SMTP id bo17mr41043764pac.98.1406582888235; Mon, 28 Jul 2014 14:28:08 -0700 (PDT) Received: from [192.168.1.79] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id gy2sm18650531pbb.50.2014.07.28.14.28.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:28:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 28 Jul 2014 14:28:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F576BA1-AFBD-4199-BDD1-9CECA101869D@gmail.com> References:

To: Albert Cabellos X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vKbmoJ1TGV-EF59IhTm1HiwfV5o Cc: LISP mailing list list Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:28:10 -0000 >> normally be in an architecture document (e.g. the architectural >>> design principles used in LISP, and the design considerations = behind >>> various components and aspects of the LISP system) is in the = second >>> document, the 'Architectural Perspective on LISP' document. >>> [I-D.ietf-lisp-perspective] >>=20 >> What is the plan for this document? >=20 > This is a non-WG document and I suggest not to cite it. >=20 > [snip] Okay. I can agree with that. >=20 >>> 7.3. Traffic Engineering >>>=20 >>> {{Suggestion by editors: Merge this section with the previous one, = TE >>> is not practical without multihoming}} >>=20 >> Well I think when you define and talk about ITRs and ETRs, and their = interworking counter-parts PITRs and PETRs, that the mention of RTRs is = a good place to introduce the concept. Then you can say how RTRs can do = TE, even if they are reached via multiple RLOCs in an RLOC-set. >=20 > lisp-te is not part of the WG and I suggest to stick to WG items. We > can include them in the use-cases appendix. RTRs are defined in RFC 6830. We need to mention them. We can say RTRs = are used in future use-cases (even though they are already being used), = such as TE, NAT-traversal, scaling mapping changes, etc. >>=20 >>> 8.2.3. Indexing Sub-system >>>=20 >>> {{suggestion by editor: rename the section to "DDT"}} >>=20 >> We have to be careful here because ALT is in RFC stages and DDT is = not even a working group document yet. We know the future is DDT, but = the future will also have other/newer approaches as well. >>=20 >=20 > DDT is an expired WG document > (https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/). >=20 > [snip] Darrel is working on getting it resubmitted. >=20 >>> 15.2.2. LISP-NAT >>>=20 >>> {{Suggestion by editors: Remove this section, LISP-NAT is not a WG >>> document neither an inter-networking mechanisms.}} >>=20 >> I agree. It is a suggestion in the interworking spec but the = deployment spec does not recommend to use it so PxTRs is what we should = focus on. >>=20 >>> 15.3. Use Through NAT Devices >>>=20 >>> {{Suggestion by editors: Remove this section, LISP-NAT is not a WG >>> document neither an inter-networking mechanisms.}} >>=20 >> This is meant to describe NAT-traversal not LISP-NAT for = interworking. I think the problem is important to solve but just explain = what I said above about how RLOCs can be private or public and the = Map-Servers can teach the xTRs what their global RLOC addresses are. >=20 > You mean section 8.4 of RFC6830? Yes. Dino From nobody Mon Jul 28 14:38:03 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42B1A024F for ; Mon, 28 Jul 2014 14:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAuf_2UJsjed for ; Mon, 28 Jul 2014 14:37:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28271A01D9 for ; Mon, 28 Jul 2014 14:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C2BC02408FF; Mon, 28 Jul 2014 14:37:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-215.clppva.east.verizon.net [70.106.134.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 25F912409CF; Mon, 28 Jul 2014 14:37:59 -0700 (PDT) Message-ID: <53D6C2B5.6010900@joelhalpern.com> Date: Mon, 28 Jul 2014 17:37:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci , Albert Cabellos References:

<4F576BA1-AFBD-4199-BDD1-9CECA101869D@gmail.com> In-Reply-To: <4F576BA1-AFBD-4199-BDD1-9CECA101869D@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/hKJnJMv1TLxgqhKI4Ws4h6b2FaA Cc: LISP mailing list list Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:38:01 -0000 I have no problem with removing the citation of perspective, as that is probably stalled and likely to be dropped if we do a good job on intro. But please, do not claim it is a non-WG document. It was adopted by the WG. Yours, Joel On 7/28/14, 5:28 PM, Dino Farinacci wrote: >>> normally be in an architecture document (e.g. the architectural >>>> design principles used in LISP, and the design considerations behind >>>> various components and aspects of the LISP system) is in the second >>>> document, the 'Architectural Perspective on LISP' document. >>>> [I-D.ietf-lisp-perspective] >>> >>> What is the plan for this document? >> >> This is a non-WG document and I suggest not to cite it. >> >> [snip] > > Okay. I can agree with that. > ... From nobody Mon Jul 28 15:13:16 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3A1A0262 for ; Mon, 28 Jul 2014 15:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndzzlu1ok2Gl for ; Mon, 28 Jul 2014 15:13:12 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297C01A01E6 for ; Mon, 28 Jul 2014 15:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=632; q=dns/txt; s=iport; t=1406585592; x=1407795192; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ph/0uimZusvPAW18ps5pRS+E82ZEAhlHHg6dmzimpqg=; b=if5k3FvGtK2Hzp0TPTvKi/EQcKzI4V8vA/T9vAItlcBp1bfksMjWpbSs ORDqr/m6kpz8j0AWyiVXWFXw+sZfmd+5yYCfOPkwYu7EhHBRb+ammEOLt wzIDYRzU9K4YHdV/AocPazOM79Cocvz7L/acjEbZLAw4VTEn5yCd9xc/w w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAN7J1lOtJV2a/2dsb2JhbABZDoMAUlcEzAuHRQGBEBZ3hAQBAQMBOjoFEAIBCDYQIRElAgQOBYguAwkIDbcVDYcTEwSNH4F6MweDL4EbAQSZR4IFjimGI4MHQmyBRQ X-IronPort-AV: E=Sophos;i="5.01,751,1400025600"; d="scan'208";a="64707502" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 28 Jul 2014 22:13:11 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6SMDB2X017654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 22:13:11 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 17:13:11 -0500 From: "Darrel Lewis (darlewis)" To: "acabello@ac.upc.edu" Thread-Topic: [lisp] Comments to draft-ietf-lisp-introduction-04.txt Thread-Index: AQHPqrEdR4cKN2R6606h9KGzS7MPNw== Date: Mon, 28 Jul 2014 22:13:10 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <5FE32A72FA2FA44F96B8365BE81DF7FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/0M723ALBrkyMH-Ia4li2wmAOnEk Cc: LISP mailing list list Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:13:14 -0000 On Jul 28, 2014, at 2:23 PM, Albert Cabellos wr= ote: >>> 8.2.3. Indexing Sub-system >>>=20 >>> {{suggestion by editor: rename the section to "DDT"}} >>=20 >> We have to be careful here because ALT is in RFC stages and DDT is not e= ven a working group document yet. We know the future is DDT, but the future= will also have other/newer approaches as well. >>=20 >=20 > DDT is an expired WG document > (https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/). >=20 > [snip] And the authors/editors are working to refresh it now, and want to progress= the document. -Darrel= From nobody Mon Jul 28 16:10:49 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C291A00CD for ; Mon, 28 Jul 2014 16:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOvweI3Y9zNP for ; Mon, 28 Jul 2014 16:10:47 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E514B1A0318 for ; Mon, 28 Jul 2014 16:10:46 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so105284igb.10 for ; Mon, 28 Jul 2014 16:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=OBgZmxwNSbtMSXSct5CvJ9tFTY19TiOXg1CERv9tvyA=; b=TALNNsoq2v0RGut2lxG+L0ol86xVx6C+5TvrYUGqDTSqQgBlyzNrzsi6j/lXh9zuCs l/Uc5NYgD6XVP7zYdRVyuDkeD0nAV4cPDGOu1F8ACITo6oTyNwINXNZyIXdk7acoLoMT DuRAEeFn/6PAX2mqu7CUCl2XDJOg8zymxPCbEG7oiipg/J9kWU5EGkLSe6R7wbHNbxsy lhZqhi9wOKtPQuwrl3IRnoMtyWyzQ10dFy9JtJEfo6PSxJbs9huCatYUIJIr2kli6r75 fUQ9Kqn++gFHna7bOWD7eeMJJFbxpOpbyS/iRzoIuo3P6tAku17DQh7mi9DCvExsc6vD GXuA== MIME-Version: 1.0 X-Received: by 10.50.43.134 with SMTP id w6mr466346igl.17.1406589046365; Mon, 28 Jul 2014 16:10:46 -0700 (PDT) Received: by 10.107.13.5 with HTTP; Mon, 28 Jul 2014 16:10:46 -0700 (PDT) In-Reply-To: <4F576BA1-AFBD-4199-BDD1-9CECA101869D@gmail.com> References:

<4F576BA1-AFBD-4199-BDD1-9CECA101869D@gmail.com> Date: Tue, 29 Jul 2014 01:10:46 +0200 Message-ID: From: Albert Cabellos To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/G1alzz45sz0s1qw3RtdAmqiSXAA Cc: LISP mailing list list Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 23:10:48 -0000 Hi Dino Please see below: On Mon, Jul 28, 2014 at 11:28 PM, Dino Farinacci wrot= e: >>> normally be in an architecture document (e.g. the architectural >>>> design principles used in LISP, and the design considerations behind >>>> various components and aspects of the LISP system) is in the second >>>> document, the 'Architectural Perspective on LISP' document. >>>> [I-D.ietf-lisp-perspective] >>> >>> What is the plan for this document? >> >> This is a non-WG document and I suggest not to cite it. >> >> [snip] > > Okay. I can agree with that. > >> >>>> 7.3. Traffic Engineering >>>> >>>> {{Suggestion by editors: Merge this section with the previous one, T= E >>>> is not practical without multihoming}} >>> >>> Well I think when you define and talk about ITRs and ETRs, and their in= terworking counter-parts PITRs and PETRs, that the mention of RTRs is a goo= d place to introduce the concept. Then you can say how RTRs can do TE, even= if they are reached via multiple RLOCs in an RLOC-set. >> >> lisp-te is not part of the WG and I suggest to stick to WG items. We >> can include them in the use-cases appendix. > > RTRs are defined in RFC 6830. We need to mention them. We can say RTRs ar= e used in future use-cases (even though they are already being used), such = as TE, NAT-traversal, scaling mapping changes, etc. > True, I forgot, I=C2=B4ll include them. Albert >>> >>>> 8.2.3. Indexing Sub-system >>>> >>>> {{suggestion by editor: rename the section to "DDT"}} >>> >>> We have to be careful here because ALT is in RFC stages and DDT is not = even a working group document yet. We know the future is DDT, but the futur= e will also have other/newer approaches as well. >>> >> >> DDT is an expired WG document >> (https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/). >> >> [snip] > > Darrel is working on getting it resubmitted. > >> >>>> 15.2.2. LISP-NAT >>>> >>>> {{Suggestion by editors: Remove this section, LISP-NAT is not a WG >>>> document neither an inter-networking mechanisms.}} >>> >>> I agree. It is a suggestion in the interworking spec but the deployment= spec does not recommend to use it so PxTRs is what we should focus on. >>> >>>> 15.3. Use Through NAT Devices >>>> >>>> {{Suggestion by editors: Remove this section, LISP-NAT is not a WG >>>> document neither an inter-networking mechanisms.}} >>> >>> This is meant to describe NAT-traversal not LISP-NAT for interworking. = I think the problem is important to solve but just explain what I said abov= e about how RLOCs can be private or public and the Map-Servers can teach th= e xTRs what their global RLOC addresses are. >> >> You mean section 8.4 of RFC6830? > > Yes. > > Dino > > From nobody Mon Jul 28 20:23:15 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26E1A0242; Mon, 28 Jul 2014 20:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUD8yANqyNtb; Mon, 28 Jul 2014 20:23:10 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD071A0005; Mon, 28 Jul 2014 20:23:09 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4C0E72AA0F; Tue, 29 Jul 2014 03:23:05 +0000 (GMT) Date: Mon, 28 Jul 2014 20:23:08 -0700 From: Marc Binderberger To: Tom Herbert Message-ID: <20140728202308389912.8bba09a4@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/4O7E3x4hD9OuT3_fcHxQ3Dde7Cc Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 03:23:12 -0000 SGVsbG8gVG9tLA0KDQpteSBwb2ludCBpcyB5b3VyICJsaW1pdHMgdGhlIHVzZWZ1bG5lc3Mi LiBUaGVyZSBpcyBzb21lIG5lZ2F0aXZlIHZpYmUgYW5kIEkgDQpkbyBub3QgYWdyZWUgd2l0 aCB0aGF0IDotKQ0KDQpBcyBtZW50aW9uZWQsIEkgYWdyZWUgd2l0aCB0aGUgc3RhdGVtZW50 IHRoYXQgaWdub3JlLW9uLXJlY2VpdmUgZmxhZ3MgbWVhbiANCnlvdSBjYW4gYWRkIG5ldyBm dW5jdGlvbmFsaXR5IG9uIHRvcCBvZiBleGlzdGluZyBvbmVzIGJ1dCBub3QgZnVuZGFtZW50 YWxseSANCmNoYW5nZSB0aGluZ3MuIEZyb20gcHJhY3RpY2FsIGV4cGVyaWVuY2Ugd2l0aCBM SVNQIGNvbnRyb2wgcGxhbmUgLSB3aGljaCBoYXMgDQppZ25vcmUtb24tcmVjZWl2ZSByZXNl cnZlZCBmaWVsZHMgLSB0aGlzIHdvcmtzIHF1aXRlIHdlbGwgYXMgaXQgYWxsb3dzIHRvIA0K YWRkLW9uIGZlYXR1cmVzIHdpdGhvdXQgYnJlYWtpbmcgdGhlIGZ1bmRhbWVudGFsIGludGVy b3Agd2l0aCBvbGRlciANCmltcGxlbWVudGF0aW9uczsgeW91IGhhdmUgdG8gZG8gaXQgInJp Z2h0IiB0byBlbnN1cmUgYSBzeXN0ZW0gbm90IA0KdW5kZXJzdGFuZGluZyB0aGUgbmV3IGZl YXR1cmUgYmVoYXZlcyBzYWZlIG9yIGF0IGxlYXN0IHJlYXNvbmFibGUgYnV0IGl0J3MgDQpk by1hYmxlLiBUaHVzIG15IHJlZmVyZW5jZSB0byBMSVNQLCBzb3JyeSB0aGlzIHdhcyBwcm9i YWJseSBjb25mdXNpbmcuDQoNCkZvciB5b3VyIExJU1AtZ3BlIGNvbW1lbnQgRmFiaW8gYW5z d2VyZWQgYWxyZWFkeSBob3cgaXQgY291bGQgd29yay4NCg0KR2VuZXJhbGx5IHNwZWFraW5n IGFib3V0IGZsYWdzLCBoYXZpbmcgYm90aCwgaWdub3JlLXdoZW4tdW5rbm93biBmbGFncyBh bmQgDQpkcm9wLXdoZW4tdW5rbm93biBmbGFncyB3b3VsZCBiZSBuaWNlIElNSE8uIFByb2Js ZW0gaXMgb3VyIGxpbWl0ZWQgc3BhY2Ugb2YgDQo2NGJpdCBzaGltIGhlYWRlciB0aG91Z2gu DQoNCg0KUmVnYXJkcywgTWFyYw0KDQoNCg0KDQpPbiBNb24sIDI4IEp1bCAyMDE0IDA4OjA4 OjMxIC0wNzAwLCBUb20gSGVyYmVydCB3cm90ZToNCj4+PiBBbGxvd2luZyB0aGUgcmVzZXJ2 ZWQgYml0cyBpbiB0aGUgaGVhZGVyIHRvIGJlIGlnbm9yZWQgb24gcmVjZWl2ZQ0KPj4+IGxp bWl0cyB0aGUgdXNlZnVsbmVzcyBpbiB0aGF0IG5ldyBiaXRzIHRoYXQgYXJlIGRlZmluZWQg Y2FuIG9ubHkgYmUNCj4+PiBhZHZpc29yeSBhbmQgbm90IGZ1bmRhbWVudGFsbHkgY2hhbmdl IGludGVycHJldGF0aW9uIG9mIHRoZSBwYWNrZXQuDQo+PiANCj4+IEkgYWdyZWUgd2l0aCB5 b3VyIHN0YXRlbWVudCBpbiB0aGUgMm5kIGhhbGYgYnV0IG5vdCB5b3VyIG9waW5pb24gYWJv dXQgdGhlDQo+PiB1c2VmdWxuZXNzLiBEb24ndCBzZWUgYSBwcm9ibGVtIGhlcmUsIExJU1Ag aXMgYSBnb29kIGV4YW1wbGUgaG93IGlnbm9yaW5nDQo+PiB1bmtub3duIGZsYWdzIHdvcmtz IHdlbGwuDQo+PiANCj4gSG93IHNvPyBBZGRpbmcgcHJvdG9jb2wgZmllbGQgdG8gTElTUC1n cGUgaGFzIHRoZSBzYW1lIGJhY2t3YXJkcw0KPiBjb21wYXRpYmlsaXR5IHByb2JsZW0gYXMg VlhMQU4tZ3BlLCBidXQgaXMgcmVzb2x2aW5nIGl0IGluIGEgZGlmZmVyZW50DQo+IHdheS4g VGhlIGFkZGl0aW9uIG9mIHRoZSBQLWJpdCByZWxpZXMgb24gc29tZSAocHJlc3VtYWJseSkg b3V0IG9mIGJhbmQNCj4gbWVjaGFuaXNtIHRvIGVuc3VyZSBwcm90b2NvbCBjb21wYXRpYmls aXR5LiBGcm9tIHRoZSBMSVNQLWdwZSBkcmFmdDoNCj4gDQo+ICJBIExJU1AtZ3BlIHJvdXRl ciBNVVNUIG5vdCBlbmNhcHN1bGF0ZSBub24tSVAgcGFja2V0cyB0byBhIExJU1ANCj4gcm91 dGVyLiAgQSBtZXRob2QgZm9yIGRldGVybWluaW5nIHRoZSBjYXBhYmlsaXRpZXMgb2YgYSBM SVNQIHJvdXRlcg0KPiAoZ3BlIG9yICJsZWdhY3kiKSBpcyBvdXQgb2YgdGhlIHNjb3BlIG9m IHRoaXMgZHJhZnQuIg0KPiANCj4gVGhhbmtzLA0KPiBUb20NCj4gDQo+PiANCj4+IFJlZ2Fy ZHMsIE1hcmMNCj4+IA0KPj4gDQo+PiANCj4+IE9uIFN1biwgMjcgSnVsIDIwMTQgMTc6Mjg6 MDEgLTA3MDAsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPj4+IE9uIFN1biwgSnVsIDI3LCAyMDE0 IGF0IDI6MjEgUE0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiANCj4+ PiB3cm90ZToNCj4+Pj4+IDIuIFRoZSBWWExBTi1HUEUgZHJhZnQgc2hvdWxkIGZvY3VzIG9u bHkgb24gdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kDQo+Pj4+PiByZXF1aXJlcyB0aGUgYXNz aWdubWVudCBvZiBhIG5ldyBVRFAgcG9ydC4gICBUaGUgZmFjdCB0aGF0IHRoZSBWWExBTi1H UEUNCj4+Pj4+IGhlYWRlciBjbG9zZWx5IHJlc2VtYmxlcyBWWExBTiBtYXkgYmUgY29udmVu aWVudCBmb3IgaW1wbGVtZW50ZXJzLCBidXQNCj4+Pj4+IHRoaXMgcHJvdG9jb2wgYnkgZGVm aW5pdGlvbiBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIFZYTEFOLg0KPj4+PiAN Cj4+Pj4gSWYgeW91IGRvIHRoYXQgdGhlbiBpdCB3aWxsIGJlIGhhcmRlciBmb3IgVlhMQU4t R1BFIHN5c3RlbXMgdG8NCj4+Pj4gaW50ZXJvcGVyYXRlIHdpdGggYSBWWExBTiBzeXN0ZW1z LiBCZWNhdXNlIGEgVlhMQU4tR1BFIHN5c3RlbSB3aWxsIG5lZWQgDQo+Pj4+IHRvDQo+Pj4+ IG9wZW4gYW5kIG1haW50YWluIDIgVURQIHNvY2tldHMuIEFuZCBhbiBpbXBsZW1lbnRhaXRv biB3aWxsIGhhdmUgdG8gYmUNCj4+Pj4gY2FyZWZ1bCB0byBub3Qgc2V0IHRoZSBQLWJpdCBm b3IgdGhlIFZYTEFOIHNvY2tldCBvciBjbGVhciB0aGUgUC1iaXQgZm9yDQo+Pj4+IFZYTEFO LUdQRSBzb2NrZXQuIFRoaXMgaXMgYWxsIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgYW5kIG9u ZSB3YXkgb3IgdGhlDQo+Pj4+IG90aGVyIHNob3VsZCBiZSB1c2VkLg0KPj4+PiANCj4+PiBJ IGFtIG5vdCBzdXJlIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLiBBRkFJQ1QgdGhlcmUgaXMg bm8gYmFja3dhcmRzDQo+Pj4gY29tcGF0aWJsZSBtZWFucyB0byB0byBhZGQgdGhlIHByb3Rv Y29sIGZpZWxkIHRvIFZYTEFOIHdoaWNoIGlzIHRoZQ0KPj4+IG1vdGl2YXRpb24gZm9yIHRo ZSBuZXcgVURQIHBvcnQsIHdoaWNoIGluIHR1cm4gaW1wbGllcyBhIG5ldyBwcm90b2NvbA0K Pj4+ICh3aGljaCBhbHNvIGltcGxpZXMgYW4gb3Bwb3J0dW5pdHkgdG8gYWRkIGEgbW9yZSBn ZW5lcmFsIHNldCBvZg0KPj4+IHByb3RvY29sIGZlYXR1cmVzIGxpa2UgdmVyc2lvbiBudW1i ZXIgYW5kIG9wdGlvbnMgZXh0ZW5zaW9ucyB3aGljaCBhcmUNCj4+PiBhbHNvIG5vdCBiYWNr d2FyZHMgY29tcGF0aWJsZSkuIE1heWJlIGl0J3MgcG9zc2libGUgdG8gYnJlYWsNCj4+PiBj b21wYXRpYmlsaXR5IHdpdGhpbiB0aGUgcHJvdG9jb2wgYW5kIGFzc3VtZSB0aGF0IG91dCBv ZiBiYW5kDQo+Pj4gbWVjaGFuaXNtcyBjb3VsZCBuZWdvdGlhdGUgdXNlIG9mIFAtYml0IHRv IGNvbXBlbnNhdGUsIGJ1dCBJIGFzc3VtZQ0KPj4+IHRoZXJlJ3MgYWxyZWFkeSBxdWl0ZSBh IGJpdCBvZiBWWExBTiBkZXBsb3ltZW50IHNvIHRoYXQgc2VlbXMgcHJldHR5DQo+Pj4gc2hh a3kgcm9idXN0bmVzcy13aXNlIHRvIG1lLg0KPj4+IA0KPj4+IEl0J3Mgbm90IGp1c3QgYWRk aW5nIHRoZSBwcm90b2NvbCBmaWVsZCB0aGF0IHdvdWxkIGJlIGFuIGlzc3VlLCBldmVuDQo+ Pj4gYWRkaW5nIHRoZSBPQU0gYml0IHRvIFZYTEFOIHdvdWxkIGJlIHByb2JsZW1hdGljLiBQ ZXIgVlhMQU4gc3BlYw0KPj4+IHVuc3BlY2lmaWVkIGZsYWcgYml0cyBhcmUgaWdub3JlZCBv biByZWNlaXZlLCBzbyBpZiB0aGUgT0FNIGJpdCB3ZXJlDQo+Pj4gc3Vic2VxdWVudGx5IGRl ZmluZWQgaW4gVlhMQU4gaXQgd2lsbCBiZSBpZ25vcmVkIGJ5IGV4aXN0aW5nDQo+Pj4gaW1w bGVtZW50YXRpb25zIGFuZCB0aGVzZSBwYWNrZXRzIHdpbGwgYmUgcHJvY2Vzc2VkIG5vcm1h bGx5LS0gdGhpcw0KPj4+IHNlZW1zIHRvIGJlIGluY29tcGF0aWJsZSB3aXRoIHRoZSBwcm9w b3NlZCBWWExBTi1ncGUgcmVxdWlyZW1lbnQgdGhhdA0KPj4+ICJXaGVuIHRoZSBPIGJpdCBp cyBzZXQgdG8gMSwgdGhlIHBhY2tldCBpcyBhbiBPQU0gcGFja2V0IGFuZCBPQU0NCj4+PiBw cm9jZXNzaW5nIE1VU1Qgb2NjdXIuIiAoYnR3ICdPQU0gcHJvY2Vzc2luZycgaXMgYXdmdWxs eSBhbWJpZ3VvdXMgdG8NCj4+PiBiZSBhIE1VU1QgaGVyZSBJTU8pLg0KPj4+IA0KPj4+IEFs bG93aW5nIHRoZSByZXNlcnZlZCBiaXRzIGluIHRoZSBoZWFkZXIgdG8gYmUgaWdub3JlZCBv biByZWNlaXZlDQo+Pj4gbGltaXRzIHRoZSB1c2VmdWxuZXNzIGluIHRoYXQgbmV3IGJpdHMg dGhhdCBhcmUgZGVmaW5lZCBjYW4gb25seSBiZQ0KPj4+IGFkdmlzb3J5IGFuZCBub3QgZnVu ZGFtZW50YWxseSBjaGFuZ2UgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHBhY2tldC4NCj4+PiBI YWQgdGhlIHJlcXVpcmVtZW50IGluIFZYTEFOIGJlZW4gdGhhdCBwYWNrZXRzIHdpdGggdW5r bm93biBiaXRzIHNldA0KPj4+IGJlIGRyb3BwZWQsIHRoZW4gYWRkaW5nIFAtYml0IGFuZCBP LWJpdCBjb3VsZCBoYXZlIGJlZW4gZG9uZSB3aXRoDQo+Pj4gYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuIFRoaXMgbWlnaHQgYmUgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IHRvDQo+Pj4g Y29uc2lkZXIgaWYgbmV3IHByb3RvY29sIChpLmUuIG5ldyBwb3J0IG51bWJlcikgaXMgdW5k ZXJ0YWtlbi4NCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gVG9tDQo+Pj4gDQo+Pj4+IEFuZCBp ZiAqaXQgd2FzIGFncmVlZCogb24gdG8gdXNlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJz IChsaWtlIHRoZSB3YXkNCj4+Pj4gTElTUCBkaWQgaXQgZm9yIEwyIHZlcnN1cyBMMyBwYWNr ZXQgZW5jYXBzdWxhdGlvbiksIHdlIHdvdWxkbid0IG5lZWQgdGhlDQo+Pj4+IFAtYml0IGF0 IGFsbC4gQnV0IHRoZXJlIHdhcyBwdXNoIGJhY2sgKGJ5IHNvbWVib2R5KSB0byBub3QgYWxs b2NhdGUNCj4+Pj4gYW5vdGhlciBwb3J0IGZvciBWWExBTiwgc28gdGhlIGRlbXV4IHdhcyBm b3JjZWQgdG8gYmUgaW4gdGhlIFZYTEFOIA0KPj4+PiBoZWFkZXIuDQo+Pj4+IA0KPj4+PiBB bmQgaXMgYWxzbyB0aGUgcmVhc29uIHRoaXMgYmFnZ2FnZSBpcyBiZWluZyBjYXJyaWVkIG92 ZXIgdGhlIExJU1Agd2hlbiANCj4+Pj4gaXQNCj4+Pj4gcmVhbGx5IGlzbid0IG5lZWRlZC4N Cj4+Pj4gDQo+Pj4+PiAzLiBUcnVlLCB0aGUgoVCiIGJpdCBpcyBub3QgbmVlZGVkIGZvciBi YWNrd2FyZCBjb21wYXRpYmlsaXR5LCBidXQgSaJtDQo+Pj4+PiBub3QgYWdhaW5zdCBpdCBp ZiB0aGVyZSBpcyB2YWx1ZSB0byBtYWtlIGl0IGNvbnNpc3RlbnQgd2l0aCB0aGUgTElTUC1H UEUNCj4+Pj4+IGhlYWRlci4NCj4+Pj4gDQo+Pj4+IFRoZXJlIGlzIG5vIGluY3JlbWVudGFs IGJlbmVmaXQgdG8gdXNlIHRoZSBQLWJpdCBmb3IgTElTUC4gV2UgaGFkIGENCj4+Pj4gc29s dXRpb24gYnV0IGJlY2F1c2Ugb2YgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUgbm8gbmV3IHBv cnQgZm9yIFZYTEFOLA0KPj4+PiBMSVNQIGlzIGFmZmVjdGVkLg0KPj4+PiANCj4+Pj4gSnVz dCBhbm90aGVyIGV4YW1wbGUgaG93IHRoZSB3b3JraW5nIGdyb3VwIGlzIHB1dHRpbmcgZWZm b3J0IGludG8gdGhpbmdzDQo+Pj4+IHRoYXQgY3JlYXRlcyBtb3JlIHdvcmsgYnV0IG5vIGJl bmVmaXQuIERvbid0IGdldCBtZSB3cm9uZywgdGhlIGNpc2NvIGd1eXMNCj4+Pj4gZGlkIHRo aXMgKHRoZSBWWExBTiBhbmQgTElTUCBzYW1lIHBvc2l0aW9uIGZvciBQLWJpdCkgZm9yIGNv bnNpc3RlbmN5LCANCj4+Pj4gYW5kDQo+Pj4+IHRoZXkgc2hvdWxkIGJlIGFwcGxhdWRlZCBm b3IgdGhhdC4gQnV0IGlmIFZYTEFOIGNvdWxkIGhhdmUgYW5vdGhlciBwb3J0DQo+Pj4+IG51 bWJlciBhc3NpZ25lZCBmb3IgIm90aGVyIHByb3RvY29scyIsIG1heWJlIHRoZSBWWExBTi1H UEUgd291bGQgbG9vayBzbw0KPj4+PiBtdWNoIGRpZmZlcmVudC4NCj4+Pj4gDQo+Pj4+IFNv bWV0aGluZyB0byB0aGluayBhYm91dCBhcyB0aGUgd29ya2luZyBncm91cCBub3cgaGFzIG5l dyBwcm9kdWN0aXZpdHkNCj4+Pj4gbWVudGFsaXR5Lg0KPj4+PiANCj4+Pj4gRGlubw0KPj4+ PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+Pj4gbnZvM0BpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4+PiANCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG52 bzMgbWFpbGluZyBsaXN0DQo+Pj4gbnZvM0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KPiA= From nobody Mon Jul 28 21:34:23 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895611A0029; Mon, 28 Jul 2014 21:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_loFIuj4P8m; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615541A0020; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so11638655pad.24 for ; Mon, 28 Jul 2014 21:34:20 -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=cOAIyk9u/QpolfOrtZofT0N5cNg+nfEvHiNgRQTqSq4=; b=nCBm5xKPjwYG3DOQcawG3H250IjVsmJfYQcBj99XCyz4F2BWWkRTr0+NWfQc1tK2Y2 rcTNSp9/GuMKcfR3uN9rmlvUqk5xrvgLcUp4QPftSlCp7tQCKK7Wm1K+w0WHm9enAtIa 1rVufzHJAIUTOjjBZ8DLxdSUcIRWZTRbqySSe3WOaSutS91xS5nKnW5lOVKCHGaBz520 2KjMTXzEl7T8Du/z3qAVVk7zkAwCDuS3s1B9Jf/3QyNteJ3RrAm8DcuzylhRuzoLvYWe XXYAMrLKnc/U+kxTusKlaN7BpJ/hvfHX85zTb9MQkq+Lntzxkwek96paqLxdCZ/FUAYy 3eUA== X-Received: by 10.69.17.230 with SMTP id gh6mr43357015pbd.0.1406608460038; Mon, 28 Jul 2014 21:34:20 -0700 (PDT) Received: from [192.168.1.79] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id jb5sm19331491pbd.73.2014.07.28.21.34.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 21:34:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <20140728202308389912.8bba09a4@sniff.de> Date: Mon, 28 Jul 2014 21:34:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/jNbpGioSLiJ2OuOQ94QcSYiBdok Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 04:34:21 -0000 > Generally speaking about flags, having both, ignore-when-unknown flags = and=20 > drop-when-unknown flags would be nice IMHO. Problem is our limited = space of=20 > 64bit shim header though. The flag bits in the LISP header are not used that way. They are = enable-bits so you can overload fields and keep the header small. The = flags are designed based on "enable-bits" in many hardware designs where = the enable-bits indicate which parallel signal lines are in effect = (voltage, verify, ECC, parity, etc). The bits do not mean anything about how the packet is handled but what = control data is transmitted with the data-packet. Dino From nobody Mon Jul 28 21:52:20 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AC51A004A; Mon, 28 Jul 2014 21:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBCAakwNI8f3; Mon, 28 Jul 2014 21:52:18 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C022A1A0026; Mon, 28 Jul 2014 21:52:17 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id DB2012AA0F; Tue, 29 Jul 2014 04:52:12 +0000 (GMT) Date: Mon, 28 Jul 2014 21:52:13 -0700 From: Marc Binderberger To: Dino Farinacci Message-ID: <20140728215213292302.e07f5538@sniff.de> In-Reply-To: <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/p-TWELoA-3FGOTP33OpnhEFYDFI Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 04:52:18 -0000 Hello Dino, thanks for this comment - that's an interesting point of view. Hmm, how do the O (or RA in another draft) and the P bit fit into this picture? They do mean something about how the packet is handled, don't they? Regards, Marc On Mon, 28 Jul 2014 21:34:15 -0700, Dino Farinacci wrote: >> Generally speaking about flags, having both, ignore-when-unknown flags and >> drop-when-unknown flags would be nice IMHO. Problem is our limited space >> of >> 64bit shim header though. > > The flag bits in the LISP header are not used that way. They are > enable-bits so you can overload fields and keep the header small. The flags > are designed based on "enable-bits" in many hardware designs where the > enable-bits indicate which parallel signal lines are in effect (voltage, > verify, ECC, parity, etc). > > The bits do not mean anything about how the packet is handled but what > control data is transmitted with the data-packet. > > Dino > From nobody Mon Jul 28 22:08:56 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F61A004A; Mon, 28 Jul 2014 22:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcI7CMoGH8pi; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42451A007C; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so11142255pdb.3 for ; Mon, 28 Jul 2014 22:08:47 -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=odzLKx4Q9xavCk8T2lfHwvwDohpyeoedkbh3sFv2utw=; b=woFQjzCSQRwlVLx2OkZyfCEjlxeX54/YTfZ4nXr+nwTuDjuBluqjCWqMZValaFhSzG 6ggqf82tOpTyMQhQ8HeaDhTAyLub5DjJjerVqT6G6Xnui++rXVCHUTpdmJaojWB9yeFJ wLRjzhd44Ni5AcUx8APVRxeN7ZWHHj68hgl6MFg/3tyd375sB/xqB/XJQcHFGu/+/Law CQpWvzV1ryv5AUFy8IWSMSoAGz4hldKVprvIeqLz4tY8jq6EQdphJM+bprdeOUamXyt7 J9MjV7XEt3gey+Bz9fOgz2lPGk4BpEUgkRmakJH+NP6KwQRhiT8/shb4hWmqemclNoNT CybA== X-Received: by 10.66.137.11 with SMTP id qe11mr43204193pab.80.1406610527287; Mon, 28 Jul 2014 22:08:47 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id qw8sm73692655pab.17.2014.07.28.22.08.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 22:08:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <20140728215213292302.e07f5538@sniff.de> Date: Mon, 28 Jul 2014 22:08:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> To: Marc Binderberger Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Nf2OLcYbVzLC86RZjkQ8Iak1XBg Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 05:08:49 -0000 > On Jul 28, 2014, at 9:52 PM, Marc Binderberger wrote: >=20 > Hello Dino, >=20 > thanks for this comment - that's an interesting point of view. >=20 > Hmm, how do the O (or RA in another draft) and the P bit fit into this=20 O-bit in LISP is not needed. I told the LUSP-GPE authors this. Because OAM-p= ackets like all other control packets go in UDP port 4342 (where encapsulate= d packets go in UDP port 4341).=20 And P-bit is not needed and the authors indicated the main motivation was to= keep consistent with VXLAN so same hardware design could do both. LISP alre= ady has port 8473 for L2 frames. And NSH is a service protocol and should ru= n above the transport layer so should have its own port and can address pack= ets anywhere. Just like any other UDP application. If that packet needs to b= e encapsulated that is a lower level function. Just like IP packets can go i= n an MPLS based LSP.=20 > picture? They do mean something about how the packet is handled, don't th= ey? I won't answer that because those bit introductions into the design are inde= ed design bugs IMO.=20 Dino= From nobody Tue Jul 29 03:58:32 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538741B27A5; Tue, 29 Jul 2014 03:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx1slHYyZba0; Tue, 29 Jul 2014 03:58:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF3D1B27A2; Tue, 29 Jul 2014 03:58:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR92588; Tue, 29 Jul 2014 10:58:25 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 11:58:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 18:58:18 +0800 From: Haoweiguo To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqm7PMm9q7yrP70OlSuBAct24iJu2p0TR Date: Tue, 29 Jul 2014 10:58:17 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

, <650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> , <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> In-Reply-To: <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/MJMxAACEN--CLfmdw3dp7-b72V8 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [lisp] =?gb2312?b?tPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90?= =?gb2312?b?b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 10:58:30 -0000 SGkgRGlubywNClRoYW5rcyBmb3IgeW91ciBkZXRhaWwgY29tbWVudHMuICBBcyBmb3IgY3VycmVu dCBWWExBTiBlbmNhcHN1bGF0aW9uLCBwbHMgc2VlIG15IGNvbW1lbnRzIGlubGluZSB3aXRoIFt3 ZWlndW9dIGJlbG93Lg0KDQpUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1 bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkIFZYTEFOLUdQRSkgc28gaXQgY2FuIHN1cHBv cnQsIG1vc3QgaW1wb3J0YW50bHkgTlNILiBUaGF0IGNoYW5nZSBhbHNvIGdpdmVzIFZYTEFOIHRv IHN1cHBvcnQgZW5jYXBzdWxhdGluZyBsYXllci0yIElQdjQgYW5kIElQdjYsIHdoaWNoIGlzIGR1 cGxpY2F0ZSBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2lt aWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QgbWF0dGVyLg0KDQpbd2VpZ3VvXTogWWVzLCBhbiBuZXcg ZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgTlNILiBC dXQgYXMgZm9yIElQdjQgYW5kIElQdjYsIGkgdGhpbmsgY3VycmVudCBWWExBTiBhbHJlYWR5IHN1 cHBvcnRlZC4gIEZvciB0aGUgbGF5ZXIgMyBpbnRlci1zdWJuZXQgdHJhZmZpYyBmcm9tIE5WRTEg dG8gTlZFMiwgaW5uZXIgZGVzdGluYXRpb24gTUFDIGlzIHRoZSBnYXRld2F5IGludGVyZmFjZSBN QUMgYXQgTlZFMi4gIEZvciB0aGUgbGF5ZXIgMiBpbnRyYS1zdWJuZXQgdHJhZmZpYyBmcm9tIE5W RTEgdG8gTlZFMiwgIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBpcyB0aGUgZGVzdGluYXRpb24gVFMn cyBNQUMuIFdoZW4gTlZFMiByZWNlaXZlcyBWWExBTiBlbmNhcHN1bGF0ZWQgdHJhZmZpYyBmcm9t IE5WRTEsIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBjYW4gYmUgdXNlZCB0byBkaWZmZXJlbnRpYXRl IGxheWVyIDIgdHJhZmZpYyBmcm9tIGxheWVyIDMgdHJhZmZpYy4gVlhMQU4gZGlzdHJpYnV0ZWQg bGF5ZXIgMyBnYXRld2F5IGNhbiBiZSByZWFsaXplZCB0aHJvdWdoIHRoZSBtZWNoYW5pc20sIE5W RSBjYW4gZm9yd2FyZCBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyIHRyYWZmaWMgYW5kIGludGVy LXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgYXQgdGhlIHNhbWUgdGltZS4NCg0KVGhhbmtzDQp3ZWln dW8gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IERp bm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lAZ21haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjI4 yNUgMjI6MTcNCsrVvP7IyzogSGFvd2VpZ3VvDQqzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0 Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQrW98ziOiBSZTogW252 bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4 bGFuLWdwZS0wMw0KDQo+IEhpIERpbm8sDQo+IFNvcnJ5LCBpIG1pc3VuZGVyc3Rvb2QgeW91LiBJ IHRoaW5rIFZYTEFOLUdQRSBjYW4gZGVmaW5lIGEgbmV3IFVEUCBwb3J0IGFuZCBhIG5ldyBkYXRh IGZvcm1hdCwgUCBiaXQNCg0KTm8gd29ycmllcy4NCg0KPiBpbiBWWExBTi1HUEUgc2VlbXMgdG8g aGF2ZSBubyBhbnkgdmFsdWUuIEFzIGZvciBiYXNpYyBpbnRlci1zdWJuZXQgbGF5ZXIgMyBjb21t dW5pY2F0aW9uIGFuZCBpbnRyYS1zdWJuZXQgbGF5ZXIgMiBjb21tdW5pY2F0aW9uIGJldHdlZW4g TlZFcywgY3VycmVudCBOVkdSRSwgVlhMQU4gYW5kIExJU1AgaGF2ZSBhbHJlYWR5IHN1cHBvcnRl ZCwNCg0KVlhMQU4gc3VwcG9ydHMgTDIgb3ZlcmxheXMgc2luY2UgaXRzIGdvYWwgaXMgdG8gZXh0 ZW5kIHN1Ym5ldHMuIExJU1Agc3VwcG9ydHMgTDMgb3ZlcmxheXMgc28gaXQgYXNzdW1lcyBzdWJu ZXRzIGFyZSBsb2NhbCAodG8gdGhlIHhUUikganVzdCBsaWtlIGluIGEgcm91dGVkIG5ldHdvcmsu IE5WR1JFIGNhbiBiZSBhIGNvbWJvLg0KDQo+IE5WR1JFLFZYTEFOLExJU1AgYW5kIFZYTEFOLUdQ RSBjYW4gYmUgaHlicmlkIHVzZWQgdG8gZm9ybSBhIE5WTzMgbmV0d29yayBpZiBvbmx5IGJhc2lj IGxheWVyIDMgYW5kDQoNClRoZXJlIGlzIG1vdGl2YXRpb24gdG8gZXh0ZW5kIGFuIGVuY2Fwc3Vs YXRpb24gaGVhZGVyICh3aGljaCBpcyBjYWxsZWQgVlhMQU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9y dCwgbW9zdCBpbXBvcnRhbnRseSBOU0guIFRoYXQgY2hhbmdlIGFsc28gZ2l2ZXMgVlhMQU4gdG8g c3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxheWVyLTIgSVB2NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVw bGljYXRlIGZ1bmN0aW9uYWxpdHkgb2YgTElTUC4gQnV0IHRoZSBoZWFkZXJzIGFyZSBzbyBzaW1p bGFyLCBpdCByZWFsbHkgZG9lbnMndCBtYXR0ZXIuDQoNCkhvd2V2ZXIsIHRoZSBQLWJpdCBpcyBu b3QgbmVlZGVkIGZvciBhbnl0aGluZyBuZXcgaW4gTElTUCBhbmQgdGhlIE9BTS1iaXQgaXMgbm90 IG5lZWRlZCBpbiBMSVNQIHNpbmNlIExJU1AgaGFzIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXIg KDQzNDIpIGZvciBjb250cm9sLXBhY2tldHMuIFZYTEFOIGRvZXMgbm90IGhhdmUgYSB3ZWxsIGRl ZmluZWQgY29udHJvbCBwcm90b2NvbCBzbyB0aGUgZGF0YS1wbGFuZSBoYXMgdG8gZXNjYXBlIG91 dCBjb250cm9sLXBsYW5lIHBha2NldHMgd2hlcmUgdGhlIGZpcnN0IG9uZSBpcyB0aGlzIG5ldyBP QU0gbWVzc2FnZS4NCg0KPiBsYXllciAyIGZvcndhcmRpbmcgcHJvY2VzcyBleGlzdHMuIEFzIGZv ciBzb21lIGV4dHJhIGZ1bmN0aW9ucyBvZiBPQU0sIHNlcnZpY2UgY2hhaW5pbmcsYW5kIGV0Yywg IG9ubHkgVlhMQU4tR1BFIGNhbiBzdXBwb3J0LCBwdXJlIFZYTEFOLUdQRSBuZXR3b3JrIHNob3Vs ZCBiZSB1c2VkIGluIHRoZXNlIGNhc2VzLg0KPiBUaGFua3MNCj4gd2VpZ3VvDQoNClJpZ2h0LCBh Z3JlZS4NCg0KRGlubw0KDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gt6K8/sjLOiBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2NpQGdtYWlsLmNvbV0N Cj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjE6MTUNCj4gytW8/sjLOiBIYW93ZWlndW8NCj4g s63LzTogVG9tIEhlcmJlcnQ7IERhdmlkIE1lbG1hbjsgbnZvM0BpZXRmLm9yZzsgTElTUCBtYWls aW5nIGxpc3QgbGlzdA0KPiDW98ziOiBSZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPg0KPj4gT24g SnVsIDI4LCAyMDE0LCBhdCA3OjI0IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29t PiB3cm90ZToNCj4+DQo+PiBBYm91dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBpIGFsc28gYWdy ZWUgd2l0aCBEaW5vLiBWWExBTi1HUEUgc2hvdWxkIGZvY3VzIG9uICB0aGUgVlhMQU4tR1BFIGhl YWRlciBhbmQgcmVxdWlyZXMgdGhlIGFzc2lnbm1lbnQgb2YgYSBuZXcgVURQIHBvcnQsIHRoZSBk YXRhIGZvcm1hdCBkb24ndCBuZWVkIGNvbnNpZGVyIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0 aCBWWExBTiBoZWFkZXIuIEkNCj4NCj4gSSB3YW50IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBzdXBw b3J0aW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgdmVyeSBpbXBvcnRhbnQgc2luY2UgVlhM QU4tcG9ydC00Nzg5IGlzIHN1cHBvcnRlZCBpbiB2YXJpb3VzIGNoaXBzIGFscmVhZHkuDQo+DQo+ IERpbm8= From nobody Tue Jul 29 05:18:42 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786301B2819; Tue, 29 Jul 2014 05:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UAXTdJIIZe9; Tue, 29 Jul 2014 05:18:18 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32691B282C; Tue, 29 Jul 2014 05:18:10 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so11553486pdj.15 for ; Tue, 29 Jul 2014 05:18:10 -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=LHRyLm087RU9i3Nka5jPJFdOMHjaFZePCBm50JQqlbA=; b=qGJbr6cfRvhUJnGYV0l/RCxKypCpJoTeHQJPzHnWdrp+sEDjsEclchYfrg+mUoQztH cX1VyMRcrCQEuDv1omH1poK3ShE/vFyLpJpzBgkdG6925OqZw0VPAVcdkMmsquoqwhe1 On7JjDP9qClDCL0E1fi/AxmYBYtgLpVf5Oa7qLkIo+PkkuCJEZJX5CfM60A+9FZFbIGz xaiMZ/7OpTMKEF7nQLluOrMv37rDKyUUCoqmfduytKNQaT0Qtjus8EvJGdIxnQWnP512 CAGp4+EO/22hAUdj5hnBUloXE3Fgt/I3qDN0LPXuwZXwjq+2uEmS2JQHTem0tTNUC/Ol Lm2A== X-Received: by 10.70.134.193 with SMTP id pm1mr1572217pdb.117.1406636290515; Tue, 29 Jul 2014 05:18:10 -0700 (PDT) Received: from [10.237.165.106] (mobile-166-137-179-195.mycingular.net. [166.137.179.195]) by mx.google.com with ESMTPSA id t3sm21851175pdf.54.2014.07.29.05.18.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 05:18:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Tue, 29 Jul 2014 05:18:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/PftkhMOYnxish6Tw-ApNTqkIzSU Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] =?utf-8?b?562U5aSNOiBbbnZvM10gQ29tbWVudHMgb24gaHR0cDovL3Rv?= =?utf-8?q?ols=2Eietf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 12:18:19 -0000 I understand what you are saying but it comes down to what the encapsulator i= s encapsulating. If the packet it is encapsulating is an L2 frame then the e= ncapsulator is supporting a layer-2 overlay service. Otherwise it is a a lay= er-3 overlay service.=20 If the dest MAC Is to the encapsulator that MAC header is stripped before a l= ayer-3 forwarding decision is made. Then, at which time the packet is forwar= ded natively or encapsulated. If the dest MAC is not the encapsulator's address, then the MAC header stays= with the packet/frame and then encapsulated.=20 The former is a layer-3 overlay and the latter is a layer-2 overlay where bo= th can be supported at the same time in one encapsulator device.=20 The former is LISP encapsulation and the latter is VXLAN encapsulation.=20 With VXLAN-GPE both cases can be supported (and most importantly with a sing= le unified control-plane).=20 So I believe VXLAN-GPE could be useful yet redundant but LISP requires no ch= anges (if LISP supports L2 which is documented in draft-smith-lisp-layer-2 u= sing a different port number).=20 Dino > On Jul 29, 2014, at 3:58 AM, Haoweiguo wrote: >=20 > Hi Dino, > Thanks for your detail comments. As for current VXLAN encapsulation, pls s= ee my comments inline with [weiguo] below. >=20 > There is motivation to extend an encapsulation header (which is called VXL= AN-GPE) so it can support, most importantly NSH. That change also gives VXLA= N to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functio= nality of LISP. But the headers are so similar, it really doens't matter. >=20 > [weiguo]: Yes, an new encapsulation header should be extended to support N= SH. But as for IPv4 and IPv6, i think current VXLAN already supported. For t= he layer 3 inter-subnet traffic from NVE1 to NVE2, inner destination MAC is t= he gateway interface MAC at NVE2. For the layer 2 intra-subnet traffic from= NVE1 to NVE2, inner destination MAC is the destination TS's MAC. When NVE2= receives VXLAN encapsulated traffic from NVE1, inner destination MAC can be= used to differentiate layer 2 traffic from layer 3 traffic. VXLAN distribut= ed layer 3 gateway can be realized through the mechanism, NVE can forward bo= th intra-subnet layer 2 traffic and inter-subnet layer 3 traffic at the same= time. >=20 > Thanks > weiguo=20 > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5 2= 2:17 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo > =E6=8A=84=E9=80=81: David Melman; nvo3@ietf.org; LISP mailing list list; T= om Herbert > =E4=B8=BB=E9=A2=98: Re: [nvo3] Comments on http://tools.ietf.org/html/draf= t-quinn-vxlan-gpe-03 >=20 >> Hi Dino, >> Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port a= nd a new data format, P bit >=20 > No worries. >=20 >> in VXLAN-GPE seems to have no any value. As for basic inter-subnet layer 3= communication and intra-subnet layer 2 communication between NVEs, current N= VGRE, VXLAN and LISP have already supported, >=20 > VXLAN supports L2 overlays since its goal is to extend subnets. LISP suppo= rts L3 overlays so it assumes subnets are local (to the xTR) just like in a r= outed network. NVGRE can be a combo. >=20 >> NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 network i= f only basic layer 3 and >=20 > There is motivation to extend an encapsulation header (which is called VXL= AN-GPE) so it can support, most importantly NSH. That change also gives VXLA= N to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functio= nality of LISP. But the headers are so similar, it really doens't matter. >=20 > However, the P-bit is not needed for anything new in LISP and the OAM-bit i= s not needed in LISP since LISP has different UDP port number (4342) for con= trol-packets. VXLAN does not have a well defined control protocol so the dat= a-plane has to escape out control-plane pakcets where the first one is this n= ew OAM message. >=20 >> layer 2 forwarding process exists. As for some extra functions of OAM, se= rvice chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE network s= hould be used in these cases. >> Thanks >> weiguo >=20 > Right, agree. >=20 > Dino >=20 >>=20 >>=20 >> ________________________________________ >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5 2= 1:15 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo >> =E6=8A=84=E9=80=81: Tom Herbert; David Melman; nvo3@ietf.org; LISP mailin= g list list >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [nvo3] Comments on http://too= ls.ietf.org/html/draft-quinn-vxlan-gpe-03 >>=20 >>> On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >>>=20 >>> About backward compatibility, i also agree with Dino. VXLAN-GPE should f= ocus on the VXLAN-GPE header and requires the assignment of a new UDP port,= the data format don't need consider backward compatibility with VXLAN heade= r. I >>=20 >> I want to make it clear that supporting backward compatibility is very im= portant since VXLAN-port-4789 is supported in various chips already. >>=20 >> Dino From nobody Tue Jul 29 20:15:32 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853371A0415; Tue, 29 Jul 2014 20:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqn2iqCgLk5r; Tue, 29 Jul 2014 20:15:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE881A04B1; Tue, 29 Jul 2014 20:15:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKR36527; Wed, 30 Jul 2014 03:15:24 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 04:15:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 11:15:20 +0800 From: Haoweiguo To: Dino Farinacci Thread-Topic: =?gb2312?B?tPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0dHA6Ly90b29scy5pZXRmLm9y?= =?gb2312?Q?g/html/draft-quinn-vxlan-gpe-03?= Thread-Index: AQHPqm7PMm9q7yrP70OlSuBAct24iJu2p0TR///MEgCAAXwojA== Date: Wed, 30 Jul 2014 03:15:19 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> , <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> In-Reply-To: <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vinQmNg3foSMjQK_M8E4J6a0_LQ Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [lisp] =?gb2312?b?tPC4tDogtPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0?= =?gb2312?b?dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdw?= =?gb2312?b?ZS0wMw==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 03:15:28 -0000 SGkgRGlubywNClZYTEFOIGNhbiB1c2UgYSB1bmlmaWVkIGVuY2Fwc3VsYXRpb24gdG8gcmVhbGl6 ZSBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyIHRyYWZmaWMgZm9yd2FyZGluZyBhbmQgaW50ZXIt c3VibmV0IGxheWVyIDMgdHJhZmZpYyBmb3J3YXJkaW5nIGF0IHRoZSBzYW1lIHRpbWUsIGlubmVy IGRlc3RpbmF0aW9uIE1BQyBpcyB1c2VkIHRvIGRpZmZlcmVuY2lhdGUgbGF5ZXIgMiB0cmFmZmlj IGZyb20gbGF5ZXIgMyB0cmFmZmljLiANCkxJU1AgdXNlcyB0d28gZGlmZmVyZW50IGVuY2Fwc3Vs YXRpb25zIGZvciBpbnRyYS1zdWJuZXQgbGF5ZXIgMiB0cmFmZmljIGZvcndhcmRpbmcgYW5kIGlu dGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9yd2FyZGluZywgVURQIHBvcnQgaXMgdXNlZCB0 byBkaWZmZXJlbmNpYXRlIGxheWVyIDIgdHJhZmZpYyBmcm9tIGxheWVyIDMgdHJhZmZpYy4NCkZy b20gdGhlb3JldGljYWwgcGVyc3BlY3RpdmUsICBib3RoIHRoZSB0d28gc29sdXRpb25zIGFyZSBh cHBsaWNhYmxlLiBGcm9tIGNvbW1lcmNpYWwgdXNlIHBlcnNwZWN0aXZlLCB0aGUgZm9ybWVyKHVu aWZpZWQgZW5jYXAgZm9yIGJvdGggbGF5ZXIgMiBhbmQgbGF5ZXIgMykgc2VlbXMgdG8gYmUgbW9y ZSBwb3B1bGFyIGN1cnJlbnRseS4NClRoYW5rcw0Kd2VpZ3VvDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IERpbm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lA Z21haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjI5yNUgMjA6MTgNCsrVvP7IyzogSGFvd2Vp Z3VvDQqzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0 IGxpc3Q7IFRvbSBIZXJiZXJ0DQrW98ziOiBSZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KDQpJIHVu ZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyBidXQgaXQgY29tZXMgZG93biB0byB3aGF0IHRo ZSBlbmNhcHN1bGF0b3IgaXMgZW5jYXBzdWxhdGluZy4gSWYgdGhlIHBhY2tldCBpdCBpcyBlbmNh cHN1bGF0aW5nIGlzIGFuIEwyIGZyYW1lIHRoZW4gdGhlIGVuY2Fwc3VsYXRvciBpcyBzdXBwb3J0 aW5nIGEgbGF5ZXItMiBvdmVybGF5IHNlcnZpY2UuIE90aGVyd2lzZSBpdCBpcyBhIGEgbGF5ZXIt MyBvdmVybGF5IHNlcnZpY2UuDQoNCklmIHRoZSBkZXN0IE1BQyBJcyB0byB0aGUgZW5jYXBzdWxh dG9yIHRoYXQgTUFDIGhlYWRlciBpcyBzdHJpcHBlZCBiZWZvcmUgYSBsYXllci0zIGZvcndhcmRp bmcgZGVjaXNpb24gaXMgbWFkZS4gVGhlbiwgYXQgd2hpY2ggdGltZSB0aGUgcGFja2V0IGlzIGZv cndhcmRlZCBuYXRpdmVseSBvciBlbmNhcHN1bGF0ZWQuDQoNCklmIHRoZSBkZXN0IE1BQyBpcyBu b3QgdGhlIGVuY2Fwc3VsYXRvcidzIGFkZHJlc3MsIHRoZW4gdGhlIE1BQyBoZWFkZXIgc3RheXMg d2l0aCB0aGUgcGFja2V0L2ZyYW1lIGFuZCB0aGVuIGVuY2Fwc3VsYXRlZC4NCg0KVGhlIGZvcm1l ciBpcyBhIGxheWVyLTMgb3ZlcmxheSBhbmQgdGhlIGxhdHRlciBpcyBhIGxheWVyLTIgb3Zlcmxh eSB3aGVyZSBib3RoIGNhbiBiZSBzdXBwb3J0ZWQgYXQgdGhlIHNhbWUgdGltZSBpbiBvbmUgZW5j YXBzdWxhdG9yIGRldmljZS4NCg0KVGhlIGZvcm1lciBpcyBMSVNQIGVuY2Fwc3VsYXRpb24gYW5k IHRoZSBsYXR0ZXIgaXMgVlhMQU4gZW5jYXBzdWxhdGlvbi4NCg0KV2l0aCBWWExBTi1HUEUgYm90 aCBjYXNlcyBjYW4gYmUgc3VwcG9ydGVkIChhbmQgbW9zdCBpbXBvcnRhbnRseSB3aXRoIGEgc2lu Z2xlIHVuaWZpZWQgY29udHJvbC1wbGFuZSkuDQoNClNvIEkgYmVsaWV2ZSBWWExBTi1HUEUgY291 bGQgYmUgdXNlZnVsIHlldCByZWR1bmRhbnQgYnV0IExJU1AgcmVxdWlyZXMgbm8gY2hhbmdlcyAo aWYgTElTUCBzdXBwb3J0cyAgTDIgd2hpY2ggaXMgZG9jdW1lbnRlZCBpbiBkcmFmdC1zbWl0aC1s aXNwLWxheWVyLTIgdXNpbmcgYSBkaWZmZXJlbnQgcG9ydCBudW1iZXIpLg0KDQpEaW5vDQoNCj4g T24gSnVsIDI5LCAyMDE0LCBhdCAzOjU4IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWku Y29tPiB3cm90ZToNCj4NCj4gSGkgRGlubywNCj4gVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21t ZW50cy4gIEFzIGZvciBjdXJyZW50IFZYTEFOIGVuY2Fwc3VsYXRpb24sIHBscyBzZWUgbXkgY29t bWVudHMgaW5saW5lIHdpdGggW3dlaWd1b10gYmVsb3cuDQo+DQo+IFRoZXJlIGlzIG1vdGl2YXRp b24gdG8gZXh0ZW5kIGFuIGVuY2Fwc3VsYXRpb24gaGVhZGVyICh3aGljaCBpcyBjYWxsZWQgVlhM QU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9ydCwgbW9zdCBpbXBvcnRhbnRseSBOU0guIFRoYXQgY2hh bmdlIGFsc28gZ2l2ZXMgVlhMQU4gdG8gc3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxheWVyLTIgSVB2 NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVwbGljYXRlIGZ1bmN0aW9uYWxpdHkgb2YgTElTUC4gQnV0 IHRoZSBoZWFkZXJzIGFyZSBzbyBzaW1pbGFyLCBpdCByZWFsbHkgZG9lbnMndCBtYXR0ZXIuDQo+ DQo+IFt3ZWlndW9dOiBZZXMsIGFuIG5ldyBlbmNhcHN1bGF0aW9uIGhlYWRlciBzaG91bGQgYmUg ZXh0ZW5kZWQgdG8gc3VwcG9ydCBOU0guIEJ1dCBhcyBmb3IgSVB2NCBhbmQgSVB2NiwgaSB0aGlu ayBjdXJyZW50IFZYTEFOIGFscmVhZHkgc3VwcG9ydGVkLiAgRm9yIHRoZSBsYXllciAzIGludGVy LXN1Ym5ldCB0cmFmZmljIGZyb20gTlZFMSB0byBOVkUyLCBpbm5lciBkZXN0aW5hdGlvbiBNQUMg aXMgdGhlIGdhdGV3YXkgaW50ZXJmYWNlIE1BQyBhdCBOVkUyLiAgRm9yIHRoZSBsYXllciAyIGlu dHJhLXN1Ym5ldCB0cmFmZmljIGZyb20gTlZFMSB0byBOVkUyLCAgaW5uZXIgZGVzdGluYXRpb24g TUFDIGlzIHRoZSBkZXN0aW5hdGlvbiBUUydzIE1BQy4gV2hlbiBOVkUyIHJlY2VpdmVzIFZYTEFO IGVuY2Fwc3VsYXRlZCB0cmFmZmljIGZyb20gTlZFMSwgaW5uZXIgZGVzdGluYXRpb24gTUFDIGNh biBiZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMyB0 cmFmZmljLiBWWExBTiBkaXN0cmlidXRlZCBsYXllciAzIGdhdGV3YXkgY2FuIGJlIHJlYWxpemVk IHRocm91Z2ggdGhlIG1lY2hhbmlzbSwgTlZFIGNhbiBmb3J3YXJkIGJvdGggaW50cmEtc3VibmV0 IGxheWVyIDIgdHJhZmZpYyBhbmQgaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZpYyBhdCB0aGUg c2FtZSB0aW1lLg0KPg0KPiBUaGFua3MNCj4gd2VpZ3VvDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2Np QGdtYWlsLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjI6MTcNCj4gytW8/sjLOiBI YW93ZWlndW8NCj4gs63LzTogRGF2aWQgTWVsbWFuOyBudm8zQGlldGYub3JnOyBMSVNQIG1haWxp bmcgbGlzdCBsaXN0OyBUb20gSGVyYmVydA0KPiDW98ziOiBSZTogW252bzNdIENvbW1lbnRzIG9u IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPg0K Pj4gSGkgRGlubywNCj4+IFNvcnJ5LCBpIG1pc3VuZGVyc3Rvb2QgeW91LiBJIHRoaW5rIFZYTEFO LUdQRSBjYW4gZGVmaW5lIGEgbmV3IFVEUCBwb3J0IGFuZCBhIG5ldyBkYXRhIGZvcm1hdCwgUCBi aXQNCj4NCj4gTm8gd29ycmllcy4NCj4NCj4+IGluIFZYTEFOLUdQRSBzZWVtcyB0byBoYXZlIG5v IGFueSB2YWx1ZS4gQXMgZm9yIGJhc2ljIGludGVyLXN1Ym5ldCBsYXllciAzIGNvbW11bmljYXRp b24gYW5kIGludHJhLXN1Ym5ldCBsYXllciAyIGNvbW11bmljYXRpb24gYmV0d2VlbiBOVkVzLCBj dXJyZW50IE5WR1JFLCBWWExBTiBhbmQgTElTUCBoYXZlIGFscmVhZHkgc3VwcG9ydGVkLA0KPg0K PiBWWExBTiBzdXBwb3J0cyBMMiBvdmVybGF5cyBzaW5jZSBpdHMgZ29hbCBpcyB0byBleHRlbmQg c3VibmV0cy4gTElTUCBzdXBwb3J0cyBMMyBvdmVybGF5cyBzbyBpdCBhc3N1bWVzIHN1Ym5ldHMg YXJlIGxvY2FsICh0byB0aGUgeFRSKSBqdXN0IGxpa2UgaW4gYSByb3V0ZWQgbmV0d29yay4gTlZH UkUgY2FuIGJlIGEgY29tYm8uDQo+DQo+PiBOVkdSRSxWWExBTixMSVNQIGFuZCBWWExBTi1HUEUg Y2FuIGJlIGh5YnJpZCB1c2VkIHRvIGZvcm0gYSBOVk8zIG5ldHdvcmsgaWYgb25seSBiYXNpYyBs YXllciAzIGFuZA0KPg0KPiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1 bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkIFZYTEFOLUdQRSkgc28gaXQgY2FuIHN1cHBv cnQsIG1vc3QgaW1wb3J0YW50bHkgTlNILiBUaGF0IGNoYW5nZSBhbHNvIGdpdmVzIFZYTEFOIHRv IHN1cHBvcnQgZW5jYXBzdWxhdGluZyBsYXllci0yIElQdjQgYW5kIElQdjYsIHdoaWNoIGlzIGR1 cGxpY2F0ZSBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2lt aWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QgbWF0dGVyLg0KPg0KPiBIb3dldmVyLCB0aGUgUC1iaXQg aXMgbm90IG5lZWRlZCBmb3IgYW55dGhpbmcgbmV3IGluIExJU1AgYW5kIHRoZSBPQU0tYml0IGlz IG5vdCBuZWVkZWQgaW4gTElTUCBzaW5jZSBMSVNQIGhhcyBkaWZmZXJlbnQgVURQIHBvcnQgbnVt YmVyICg0MzQyKSBmb3IgY29udHJvbC1wYWNrZXRzLiBWWExBTiBkb2VzIG5vdCBoYXZlIGEgd2Vs bCBkZWZpbmVkIGNvbnRyb2wgcHJvdG9jb2wgc28gdGhlIGRhdGEtcGxhbmUgaGFzIHRvIGVzY2Fw ZSBvdXQgY29udHJvbC1wbGFuZSBwYWtjZXRzIHdoZXJlIHRoZSBmaXJzdCBvbmUgaXMgdGhpcyBu ZXcgT0FNIG1lc3NhZ2UuDQo+DQo+PiBsYXllciAyIGZvcndhcmRpbmcgcHJvY2VzcyBleGlzdHMu IEFzIGZvciBzb21lIGV4dHJhIGZ1bmN0aW9ucyBvZiBPQU0sIHNlcnZpY2UgY2hhaW5pbmcsYW5k IGV0YywgIG9ubHkgVlhMQU4tR1BFIGNhbiBzdXBwb3J0LCBwdXJlIFZYTEFOLUdQRSBuZXR3b3Jr IHNob3VsZCBiZSB1c2VkIGluIHRoZXNlIGNhc2VzLg0KPj4gVGhhbmtzDQo+PiB3ZWlndW8NCj4N Cj4gUmlnaHQsIGFncmVlLg0KPg0KPiBEaW5vDQo+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ILeivP7IyzogRGlubyBGYXJpbmFjY2kgW2Zh cmluYWNjaUBnbWFpbC5jb21dDQo+PiC3osvNyrG85DogMjAxNMTqN9TCMjjI1SAyMToxNQ0KPj4g ytW8/sjLOiBIYW93ZWlndW8NCj4+ILOty806IFRvbSBIZXJiZXJ0OyBEYXZpZCBNZWxtYW47IG52 bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCj4+INb3zOI6IFJlOiC08Li0OiBb bnZvM10gQ29tbWVudHMgb24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4t dnhsYW4tZ3BlLTAzDQo+Pg0KPj4+IE9uIEp1bCAyOCwgMjAxNCwgYXQgNzoyNCBBTSwgSGFvd2Vp Z3VvIDxoYW93ZWlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBBYm91dCBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5LCBpIGFsc28gYWdyZWUgd2l0aCBEaW5vLiBWWExBTi1HUEUgc2hvdWxk IGZvY3VzIG9uICB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVxdWlyZXMgdGhlIGFzc2lnbm1l bnQgb2YgYSBuZXcgVURQIHBvcnQsIHRoZSBkYXRhIGZvcm1hdCBkb24ndCBuZWVkIGNvbnNpZGVy IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBWWExBTiBoZWFkZXIuIEkNCj4+DQo+PiBJIHdh bnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHN1cHBvcnRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSBpcyB2ZXJ5IGltcG9ydGFudCBzaW5jZSBWWExBTi1wb3J0LTQ3ODkgaXMgc3VwcG9ydGVkIGlu IHZhcmlvdXMgY2hpcHMgYWxyZWFkeS4NCj4+DQo+PiBEaW5v From nobody Tue Jul 29 23:40:30 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE21A0418; Tue, 29 Jul 2014 23:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.999 X-Spam-Level: **** X-Spam-Status: No, score=4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8YuMiV2LvJe; Tue, 29 Jul 2014 23:40:22 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BF91A03D4; Tue, 29 Jul 2014 23:40:21 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 5603F2AA0F; Wed, 30 Jul 2014 06:40:16 +0000 (GMT) Date: Tue, 29 Jul 2014 23:40:19 -0700 From: Marc Binderberger To: Haoweiguo Message-ID: <20140729234019087723.ceceb885@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/oKJj8sJJNsT2Sbjdkc2aizEZNEk Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] =?gb2312?b?W252bzNdILTwuLQ6ILTwuLQ6IENvbW1lbnRzIG9uIGh0?= =?gb2312?b?dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdw?= =?gb2312?b?ZS0wMw==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 06:40:24 -0000 SGVsbG8gV2VpZ3VvLA0KDQpJIHdvdWxkIHNheSB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgaWYg eW91ciAibGF5ZXItMyIgc2VydmljZSBpcyBhY3R1YWxseSBhIA0KbGF5ZXItMiBFdGhlcm5l dCBmcmFtZSB3aXRoIHRoZSBkZXN0aW5hdGlvbiBNQUMgb2YgdGhlIGVuY2Fwc3VsYXRlZCBw YWNrZXQgDQpiZWluZyBpZGVudGljYWwgd2l0aCB0aGUgTUFDIG9mIHRoZSBkZWNhcHN1bGF0 aW5nIHN5c3RlbSwgY29tcGFyZWQgdG8gYSANCmxheWVyLTMgc2VydmljZSB3aGVyZSB5b3Vy IHdob2xlIHByb2Nlc3Npbmcgc3RheXMgc29sZWx5IGluIHRoZSBsYXllci0zLCBubyANCk1B QyBpbnZvbHZlZC4NCg0KSWYgSSB3YW50IHRvIGRlZmluZSBhIGxheWVyLTMgZW5jYXBzdWxh dGlvbiAobGlrZSBMSVNQLCBsaWtlIHRoZSBwcm9wb3NlZCANClZ4TEFOLWdwZSB3aXRoIElQ djQvdjYgYXMgcHJvdG9jb2wpIHRoZW4gaGF2aW5nIGFueSBsYXllci0yIGluIHRoZSBwcm9j ZXNzIA0Kc2VlbXMgYSBiaXQgIm9kZCIuIFdvcnNlLCB0aGUgaW52b2x2ZWQgc3lzdGVtcyBt YXkgbm90IGhhdmUgdGhpcyBsYXllci0yIA0KbG9naWMuIExJU1AgZm9yIGV4YW1wbGUgaXMg b2Z0ZW4gdXNlZCBpbiB0aGUgV0FOLCBldmVuIHdoZW4gc29tZSANCmVuY2Fwc3VsYXRvci9k ZWNhcHN1bGF0b3IgYXJlIERDIHN3aXRjaGVzLiBTb21lIG9mIHRoZXNlIFdBTiBzeXN0ZW1z IG1heSBiZSANCnB1cmUgSVB2NC92NiByb3V0ZXJzLg0KDQoNCkluIG90aGVyIHdvcmRzOiBo YXZpbmcgYm90aCBhIGxheWVyLTIgKFZ4TEFOKSBhbmQgYSBsYXllci0zIChMSVNQKSANCmVu Y2Fwc3VsYXRpb24gbWFrZXMgZ29vZCBzZW5zZS4gVGhlIHF1ZXN0aW9uIGlzOiBzaGFsbCB3 ZSBrZWVwIGl0IHNlcGFyYXRlZCANCmFzIGl0IGlzIHRvZGF5IGFzICJMSVNQIiBhbmQgIlZ4 TEFOIiBvciBjb21iaW5lIHRoZSAoZXhwZW5zaXZlKSBtdWx0aXBsZSBkYXRhIA0KcGxhbmVz IGludG8gb25lIFZ4TEFOLWdwZS4NCg0KDQpSZWdhcmRzLCBNYXJjDQoNCg0KDQoNCg0KT24g V2VkLCAzMCBKdWwgMjAxNCAwMzoxNToxOSArMDAwMCwgSGFvd2VpZ3VvIHdyb3RlOg0KPiBI aSBEaW5vLA0KPiBWWExBTiBjYW4gdXNlIGEgdW5pZmllZCBlbmNhcHN1bGF0aW9uIHRvIHJl YWxpemUgYm90aCBpbnRyYS1zdWJuZXQgbGF5ZXIgMiANCj4gdHJhZmZpYyBmb3J3YXJkaW5n IGFuZCBpbnRlci1zdWJuZXQgbGF5ZXIgMyB0cmFmZmljIGZvcndhcmRpbmcgYXQgdGhlIHNh bWUgDQo+IHRpbWUsIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBpcyB1c2VkIHRvIGRpZmZlcmVu Y2lhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gDQo+IGxheWVyIDMgdHJhZmZpYy4gDQo+IExJ U1AgdXNlcyB0d28gZGlmZmVyZW50IGVuY2Fwc3VsYXRpb25zIGZvciBpbnRyYS1zdWJuZXQg bGF5ZXIgMiB0cmFmZmljIA0KPiBmb3J3YXJkaW5nIGFuZCBpbnRlci1zdWJuZXQgbGF5ZXIg MyB0cmFmZmljIGZvcndhcmRpbmcsIFVEUCBwb3J0IGlzIHVzZWQgdG8gDQo+IGRpZmZlcmVu Y2lhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMyB0cmFmZmljLg0KPiBGcm9tIHRo ZW9yZXRpY2FsIHBlcnNwZWN0aXZlLCAgYm90aCB0aGUgdHdvIHNvbHV0aW9ucyBhcmUgYXBw bGljYWJsZS4gRnJvbSANCj4gY29tbWVyY2lhbCB1c2UgcGVyc3BlY3RpdmUsIHRoZSBmb3Jt ZXIodW5pZmllZCBlbmNhcCBmb3IgYm90aCBsYXllciAyIGFuZCANCj4gbGF5ZXIgMykgc2Vl bXMgdG8gYmUgbW9yZSBwb3B1bGFyIGN1cnJlbnRseS4NCj4gVGhhbmtzDQo+IHdlaWd1bw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7Iyzog RGlubyBGYXJpbmFjY2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQo+ILeiy83KsbzkOiAyMDE0 xOo31MIyOcjVIDIwOjE4DQo+IMrVvP7IyzogSGFvd2VpZ3VvDQo+ILOty806IERhdmlkIE1l bG1hbjsgbnZvM0BpZXRmLm9yZzsgTElTUCBtYWlsaW5nIGxpc3QgbGlzdDsgVG9tIEhlcmJl cnQNCj4g1vfM4jogUmU6ILTwuLQ6IFtudm8zXSBDb21tZW50cyBvbiANCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQo+IA0KPiBJIHVu ZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyBidXQgaXQgY29tZXMgZG93biB0byB3aGF0 IHRoZSBlbmNhcHN1bGF0b3IgDQo+IGlzIGVuY2Fwc3VsYXRpbmcuIElmIHRoZSBwYWNrZXQg aXQgaXMgZW5jYXBzdWxhdGluZyBpcyBhbiBMMiBmcmFtZSB0aGVuIHRoZSANCj4gZW5jYXBz dWxhdG9yIGlzIHN1cHBvcnRpbmcgYSBsYXllci0yIG92ZXJsYXkgc2VydmljZS4gT3RoZXJ3 aXNlIGl0IGlzIGEgYSANCj4gbGF5ZXItMyBvdmVybGF5IHNlcnZpY2UuDQo+IA0KPiBJZiB0 aGUgZGVzdCBNQUMgSXMgdG8gdGhlIGVuY2Fwc3VsYXRvciB0aGF0IE1BQyBoZWFkZXIgaXMg c3RyaXBwZWQgYmVmb3JlIGEgDQo+IGxheWVyLTMgZm9yd2FyZGluZyBkZWNpc2lvbiBpcyBt YWRlLiBUaGVuLCBhdCB3aGljaCB0aW1lIHRoZSBwYWNrZXQgaXMgDQo+IGZvcndhcmRlZCBu YXRpdmVseSBvciBlbmNhcHN1bGF0ZWQuDQo+IA0KPiBJZiB0aGUgZGVzdCBNQUMgaXMgbm90 IHRoZSBlbmNhcHN1bGF0b3IncyBhZGRyZXNzLCB0aGVuIHRoZSBNQUMgaGVhZGVyIA0KPiBz dGF5cyB3aXRoIHRoZSBwYWNrZXQvZnJhbWUgYW5kIHRoZW4gZW5jYXBzdWxhdGVkLg0KPiAN Cj4gVGhlIGZvcm1lciBpcyBhIGxheWVyLTMgb3ZlcmxheSBhbmQgdGhlIGxhdHRlciBpcyBh IGxheWVyLTIgb3ZlcmxheSB3aGVyZSANCj4gYm90aCBjYW4gYmUgc3VwcG9ydGVkIGF0IHRo ZSBzYW1lIHRpbWUgaW4gb25lIGVuY2Fwc3VsYXRvciBkZXZpY2UuDQo+IA0KPiBUaGUgZm9y bWVyIGlzIExJU1AgZW5jYXBzdWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBWWExBTiBlbmNh cHN1bGF0aW9uLg0KPiANCj4gV2l0aCBWWExBTi1HUEUgYm90aCBjYXNlcyBjYW4gYmUgc3Vw cG9ydGVkIChhbmQgbW9zdCBpbXBvcnRhbnRseSB3aXRoIGEgDQo+IHNpbmdsZSB1bmlmaWVk IGNvbnRyb2wtcGxhbmUpLg0KPiANCj4gU28gSSBiZWxpZXZlIFZYTEFOLUdQRSBjb3VsZCBi ZSB1c2VmdWwgeWV0IHJlZHVuZGFudCBidXQgTElTUCByZXF1aXJlcyBubyANCj4gY2hhbmdl cyAoaWYgTElTUCBzdXBwb3J0cyAgTDIgd2hpY2ggaXMgZG9jdW1lbnRlZCBpbiANCj4gZHJh ZnQtc21pdGgtbGlzcC1sYXllci0yIHVzaW5nIGEgZGlmZmVyZW50IHBvcnQgbnVtYmVyKS4N Cj4gDQo+IERpbm8NCj4gDQo+PiBPbiBKdWwgMjksIDIwMTQsIGF0IDM6NTggQU0sIEhhb3dl aWd1byA8aGFvd2VpZ3VvQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBEaW5vLA0K Pj4gVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21tZW50cy4gIEFzIGZvciBjdXJyZW50IFZY TEFOIGVuY2Fwc3VsYXRpb24sIHBscyANCj4+IHNlZSBteSBjb21tZW50cyBpbmxpbmUgd2l0 aCBbd2VpZ3VvXSBiZWxvdy4NCj4+IA0KPj4gVGhlcmUgaXMgbW90aXZhdGlvbiB0byBleHRl bmQgYW4gZW5jYXBzdWxhdGlvbiBoZWFkZXIgKHdoaWNoIGlzIGNhbGxlZCANCj4+IFZYTEFO LUdQRSkgc28gaXQgY2FuIHN1cHBvcnQsIG1vc3QgaW1wb3J0YW50bHkgTlNILiBUaGF0IGNo YW5nZSBhbHNvIGdpdmVzIA0KPj4gVlhMQU4gdG8gc3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxh eWVyLTIgSVB2NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVwbGljYXRlIA0KPj4gZnVuY3Rpb25h bGl0eSBvZiBMSVNQLiBCdXQgdGhlIGhlYWRlcnMgYXJlIHNvIHNpbWlsYXIsIGl0IHJlYWxs eSBkb2Vucyd0IA0KPj4gbWF0dGVyLg0KPj4gDQo+PiBbd2VpZ3VvXTogWWVzLCBhbiBuZXcg ZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgDQo+ PiBOU0guIEJ1dCBhcyBmb3IgSVB2NCBhbmQgSVB2NiwgaSB0aGluayBjdXJyZW50IFZYTEFO IGFscmVhZHkgc3VwcG9ydGVkLiAgDQo+PiBGb3IgdGhlIGxheWVyIDMgaW50ZXItc3VibmV0 IHRyYWZmaWMgZnJvbSBOVkUxIHRvIE5WRTIsIGlubmVyIGRlc3RpbmF0aW9uIA0KPj4gTUFD IGlzIHRoZSBnYXRld2F5IGludGVyZmFjZSBNQUMgYXQgTlZFMi4gIEZvciB0aGUgbGF5ZXIg MiBpbnRyYS1zdWJuZXQgDQo+PiB0cmFmZmljIGZyb20gTlZFMSB0byBOVkUyLCAgaW5uZXIg ZGVzdGluYXRpb24gTUFDIGlzIHRoZSBkZXN0aW5hdGlvbiBUUydzIA0KPj4gTUFDLiBXaGVu IE5WRTIgcmVjZWl2ZXMgVlhMQU4gZW5jYXBzdWxhdGVkIHRyYWZmaWMgZnJvbSBOVkUxLCBp bm5lciANCj4+IGRlc3RpbmF0aW9uIE1BQyBjYW4gYmUgdXNlZCB0byBkaWZmZXJlbnRpYXRl IGxheWVyIDIgdHJhZmZpYyBmcm9tIGxheWVyIDMgDQo+PiB0cmFmZmljLiBWWExBTiBkaXN0 cmlidXRlZCBsYXllciAzIGdhdGV3YXkgY2FuIGJlIHJlYWxpemVkIHRocm91Z2ggdGhlIA0K Pj4gbWVjaGFuaXNtLCBOVkUgY2FuIGZvcndhcmQgYm90aCBpbnRyYS1zdWJuZXQgbGF5ZXIg MiB0cmFmZmljIGFuZCANCj4+IGludGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgYXQgdGhl IHNhbWUgdGltZS4NCj4+IA0KPj4gVGhhbmtzDQo+PiB3ZWlndW8NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ILeivP7IyzogRGlubyBGYXJpbmFj Y2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQo+PiC3osvNyrG85DogMjAxNMTqN9TCMjjI1SAy MjoxNw0KPj4gytW8/sjLOiBIYW93ZWlndW8NCj4+ILOty806IERhdmlkIE1lbG1hbjsgbnZv M0BpZXRmLm9yZzsgTElTUCBtYWlsaW5nIGxpc3QgbGlzdDsgVG9tIEhlcmJlcnQNCj4+INb3 zOI6IFJlOiBbbnZvM10gQ29tbWVudHMgb24gDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1xdWlubi12eGxhbi1ncGUtMDMNCj4+IA0KPj4+IEhpIERpbm8sDQo+Pj4g U29ycnksIGkgbWlzdW5kZXJzdG9vZCB5b3UuIEkgdGhpbmsgVlhMQU4tR1BFIGNhbiBkZWZp bmUgYSBuZXcgVURQIHBvcnQgDQo+Pj4gYW5kIGEgbmV3IGRhdGEgZm9ybWF0LCBQIGJpdA0K Pj4gDQo+PiBObyB3b3JyaWVzLg0KPj4gDQo+Pj4gaW4gVlhMQU4tR1BFIHNlZW1zIHRvIGhh dmUgbm8gYW55IHZhbHVlLiBBcyBmb3IgYmFzaWMgaW50ZXItc3VibmV0IGxheWVyIA0KPj4+ IDMgY29tbXVuaWNhdGlvbiBhbmQgaW50cmEtc3VibmV0IGxheWVyIDIgY29tbXVuaWNhdGlv biBiZXR3ZWVuIE5WRXMsIA0KPj4+IGN1cnJlbnQgTlZHUkUsIFZYTEFOIGFuZCBMSVNQIGhh dmUgYWxyZWFkeSBzdXBwb3J0ZWQsDQo+PiANCj4+IFZYTEFOIHN1cHBvcnRzIEwyIG92ZXJs YXlzIHNpbmNlIGl0cyBnb2FsIGlzIHRvIGV4dGVuZCBzdWJuZXRzLiBMSVNQIA0KPj4gc3Vw cG9ydHMgTDMgb3ZlcmxheXMgc28gaXQgYXNzdW1lcyBzdWJuZXRzIGFyZSBsb2NhbCAodG8g dGhlIHhUUikganVzdCANCj4+IGxpa2UgaW4gYSByb3V0ZWQgbmV0d29yay4gTlZHUkUgY2Fu IGJlIGEgY29tYm8uDQo+PiANCj4+PiBOVkdSRSxWWExBTixMSVNQIGFuZCBWWExBTi1HUEUg Y2FuIGJlIGh5YnJpZCB1c2VkIHRvIGZvcm0gYSBOVk8zIG5ldHdvcmsgDQo+Pj4gaWYgb25s eSBiYXNpYyBsYXllciAzIGFuZA0KPj4gDQo+PiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4 dGVuZCBhbiBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkIA0KPj4gVlhM QU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9ydCwgbW9zdCBpbXBvcnRhbnRseSBOU0guIFRoYXQg Y2hhbmdlIGFsc28gZ2l2ZXMgDQo+PiBWWExBTiB0byBzdXBwb3J0IGVuY2Fwc3VsYXRpbmcg bGF5ZXItMiBJUHY0IGFuZCBJUHY2LCB3aGljaCBpcyBkdXBsaWNhdGUgDQo+PiBmdW5jdGlv bmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2ltaWxhciwgaXQgcmVh bGx5IGRvZW5zJ3QgDQo+PiBtYXR0ZXIuDQo+PiANCj4+IEhvd2V2ZXIsIHRoZSBQLWJpdCBp cyBub3QgbmVlZGVkIGZvciBhbnl0aGluZyBuZXcgaW4gTElTUCBhbmQgdGhlIE9BTS1iaXQg DQo+PiBpcyBub3QgbmVlZGVkIGluIExJU1Agc2luY2UgTElTUCBoYXMgZGlmZmVyZW50IFVE UCBwb3J0IG51bWJlciAoNDM0MikgZm9yIA0KPj4gY29udHJvbC1wYWNrZXRzLiBWWExBTiBk b2VzIG5vdCBoYXZlIGEgd2VsbCBkZWZpbmVkIGNvbnRyb2wgcHJvdG9jb2wgc28gDQo+PiB0 aGUgZGF0YS1wbGFuZSBoYXMgdG8gZXNjYXBlIG91dCBjb250cm9sLXBsYW5lIHBha2NldHMg d2hlcmUgdGhlIGZpcnN0IG9uZSANCj4+IGlzIHRoaXMgbmV3IE9BTSBtZXNzYWdlLg0KPj4g DQo+Pj4gbGF5ZXIgMiBmb3J3YXJkaW5nIHByb2Nlc3MgZXhpc3RzLiBBcyBmb3Igc29tZSBl eHRyYSBmdW5jdGlvbnMgb2YgT0FNLCANCj4+PiBzZXJ2aWNlIGNoYWluaW5nLGFuZCBldGMs ICBvbmx5IFZYTEFOLUdQRSBjYW4gc3VwcG9ydCwgcHVyZSBWWExBTi1HUEUgDQo+Pj4gbmV0 d29yayBzaG91bGQgYmUgdXNlZCBpbiB0aGVzZSBjYXNlcy4NCj4+PiBUaGFua3MNCj4+PiB3 ZWlndW8NCj4+IA0KPj4gUmlnaHQsIGFncmVlLg0KPj4gDQo+PiBEaW5vDQo+PiANCj4+PiAN Cj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gt6K8/sjLOiBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4+PiC3 osvNyrG85DogMjAxNMTqN9TCMjjI1SAyMToxNQ0KPj4+IMrVvP7IyzogSGFvd2VpZ3VvDQo+ Pj4gs63LzTogVG9tIEhlcmJlcnQ7IERhdmlkIE1lbG1hbjsgbnZvM0BpZXRmLm9yZzsgTElT UCBtYWlsaW5nIGxpc3QgbGlzdA0KPj4+INb3zOI6IFJlOiC08Li0OiBbbnZvM10gQ29tbWVu dHMgb24gDQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhs YW4tZ3BlLTAzDQo+Pj4gDQo+Pj4+IE9uIEp1bCAyOCwgMjAxNCwgYXQgNzoyNCBBTSwgSGFv d2VpZ3VvIDxoYW93ZWlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBBYm91 dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBpIGFsc28gYWdyZWUgd2l0aCBEaW5vLiBWWExB Ti1HUEUgc2hvdWxkIA0KPj4+PiBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5k IHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUCANCj4+Pj4gcG9ydCwgdGhl IGRhdGEgZm9ybWF0IGRvbid0IG5lZWQgY29uc2lkZXIgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSB3aXRoIA0KPj4+PiBWWExBTiBoZWFkZXIuIEkNCj4+PiANCj4+PiBJIHdhbnQgdG8gbWFr ZSBpdCBjbGVhciB0aGF0IHN1cHBvcnRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyB2 ZXJ5IA0KPj4+IGltcG9ydGFudCBzaW5jZSBWWExBTi1wb3J0LTQ3ODkgaXMgc3VwcG9ydGVk IGluIHZhcmlvdXMgY2hpcHMgYWxyZWFkeS4NCj4+PiANCj4+PiBEaW5vDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGlu ZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9udm8z From nobody Wed Jul 30 01:28:54 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66201B29E7 for ; Wed, 30 Jul 2014 01:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJVJt5NKMB0s for ; Wed, 30 Jul 2014 01:28: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 B171C1B29DF for ; Wed, 30 Jul 2014 01:28:50 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id BD8B52AA0F; Wed, 30 Jul 2014 08:28:48 +0000 (GMT) Date: Wed, 30 Jul 2014 01:28:50 -0700 From: Marc Binderberger To: jacabello@ac.upc.edu, damien.saucez@inria.fr Message-ID: <20140730012850548628.87a075d1@sniff.de> In-Reply-To: <53C6ACAC.7090407@joelhalpern.com> References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/QEHcvEAc4x0grAo42odvn94X2GA Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: I-D ACTION:draft-ietf-lisp-introduction-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 08:28:52 -0000 Hello Albert and Damien, quite a document! I'm looking forward for a version where your Editor's suggestions are implemented. I agree with the suggestions. What I do like - and hope it will be maintained in future versions - is the lot of references. It's a great read (I regularly get lost in looking up the referenced RFCs ;-) In part II the text sometimes is very detailed - an example is section 13.x: what fields are contained in the messages is described in the particular RFCs and I don't see a gain describing it here again, even briefly. In this sense I support all suggestions that simplify text. From an introduction text I would expect it explains the building blocks like MR, MS, iTR and eTR (to stay with the example of the mapping system) and what messages exist in between. And then a reference to the particular RFCs for details. Nevertheless, overall an interesting read. Regards, Marc On Wed, 16 Jul 2014 12:47:40 -0400, Joel M. Halpern wrote: > The chairs and listed authors are happy to call the WGs attention to the > latest revision of the LISP Introduction draft. > If you can take a look at this before the meeting in Toronto, that would be > good. > Our apologies for the late notice. > > Yours, > Joel > > > -------- Original Message -------- > Subject: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt > Date: Wed, 16 Jul 2014 09:40:43 -0700 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: lisp@ietf.org > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol Working > Group of the IETF. > > Title : An Architectural Introduction to the LISP > Location-Identity Separation System > Author(s) : D. Saucez, et al > Filename : draft-ietf-lisp-introduction > Pages : 59 > Date : 2014-07-16 > > This document is an introductory overview of the Locator/ID > Separation Protocol, it describes the major concepts and functional > sub-systems of LISP and the interactions between them. > > > A URL for this Internet-Draft is: > https://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jul 30 02:29:56 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB421B2A3D; Wed, 30 Jul 2014 02:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqeJ9N4-XUy2; Wed, 30 Jul 2014 02:29:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7F31B2A25; Wed, 30 Jul 2014 02:29:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS25540; Wed, 30 Jul 2014 09:29:49 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 10:29:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 17:29:42 +0800 From: Haoweiguo To: Marc Binderberger Thread-Topic: =?gb2312?B?W252bzNdILTwuLQ6ILTwuLQ6ICBDb21tZW50cyBvbiBodHRwOi8vdG9vbHMu?= =?gb2312?Q?ietf.org/html/draft-quinn-vxlan-gpe-03?= Thread-Index: AQHPq8UpZvCMYhqnVE2ZDwe/al7MtZu4UrtB Date: Wed, 30 Jul 2014 09:29:41 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> , <20140729234019087723.ceceb885@sniff.de> In-Reply-To: <20140729234019087723.ceceb885@sniff.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/rIbIhMXixBrQJs3kusQWYrrjOjs Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: [lisp] =?gb2312?b?tPC4tDogW252bzNdILTwuLQ6ILTwuLQ6ICBDb21tZW50?= =?gb2312?b?cyBvbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi12?= =?gb2312?b?eGxhbi1ncGUtMDM=?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 09:29:54 -0000 SGkgTWFyYywNCg0KVlhMQU4tR1BFIGhhdmUgbmV4dCBwcm90b2NvbCBmaWVsZCwgc28gaXQgY2Fu IGNvbWJpbmUgbXVsdGlwbGUgZGF0YSBwbGFuZXMgaW50byBvbmUgVlhMQU4tZ3BlLiBDdXJyZW50 bHkgaW5uZXIgZGVzdGluYXRpb24gTUFDIGNhbiBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIGxheWVy IDIgYW5kIGxheWVyIDMgdHJhZmZpYyBhdCBlZ3Jlc3MgTlZFLg0KVGhhbmtzDQp3ZWlndW8NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTWFyYyBCaW5k ZXJiZXJnZXIgW21hcmNAc25pZmYuZGVdDQq3osvNyrG85DogMjAxNMTqN9TCMzDI1SAxNDo0MA0K ytW8/sjLOiBIYW93ZWlndW8NCrOty806IERpbm8gRmFyaW5hY2NpOyBEYXZpZCBNZWxtYW47IG52 bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQrW98ziOiBS ZTogW252bzNdILTwuLQ6ILTwuLQ6ICBDb21tZW50cyBvbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1xdWlubi12eGxhbi1ncGUtMDMNCg0KSGVsbG8gV2VpZ3VvLA0KDQpJIHdvdWxk IHNheSB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgaWYgeW91ciAibGF5ZXItMyIgc2VydmljZSBpcyBh Y3R1YWxseSBhDQpsYXllci0yIEV0aGVybmV0IGZyYW1lIHdpdGggdGhlIGRlc3RpbmF0aW9uIE1B QyBvZiB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldA0KYmVpbmcgaWRlbnRpY2FsIHdpdGggdGhlIE1B QyBvZiB0aGUgZGVjYXBzdWxhdGluZyBzeXN0ZW0sIGNvbXBhcmVkIHRvIGENCmxheWVyLTMgc2Vy dmljZSB3aGVyZSB5b3VyIHdob2xlIHByb2Nlc3Npbmcgc3RheXMgc29sZWx5IGluIHRoZSBsYXll ci0zLCBubw0KTUFDIGludm9sdmVkLg0KDQpJZiBJIHdhbnQgdG8gZGVmaW5lIGEgbGF5ZXItMyBl bmNhcHN1bGF0aW9uIChsaWtlIExJU1AsIGxpa2UgdGhlIHByb3Bvc2VkDQpWeExBTi1ncGUgd2l0 aCBJUHY0L3Y2IGFzIHByb3RvY29sKSB0aGVuIGhhdmluZyBhbnkgbGF5ZXItMiBpbiB0aGUgcHJv Y2Vzcw0Kc2VlbXMgYSBiaXQgIm9kZCIuIFdvcnNlLCB0aGUgaW52b2x2ZWQgc3lzdGVtcyBtYXkg bm90IGhhdmUgdGhpcyBsYXllci0yDQpsb2dpYy4gTElTUCBmb3IgZXhhbXBsZSBpcyBvZnRlbiB1 c2VkIGluIHRoZSBXQU4sIGV2ZW4gd2hlbiBzb21lDQplbmNhcHN1bGF0b3IvZGVjYXBzdWxhdG9y IGFyZSBEQyBzd2l0Y2hlcy4gU29tZSBvZiB0aGVzZSBXQU4gc3lzdGVtcyBtYXkgYmUNCnB1cmUg SVB2NC92NiByb3V0ZXJzLg0KDQoNCkluIG90aGVyIHdvcmRzOiBoYXZpbmcgYm90aCBhIGxheWVy LTIgKFZ4TEFOKSBhbmQgYSBsYXllci0zIChMSVNQKQ0KZW5jYXBzdWxhdGlvbiBtYWtlcyBnb29k IHNlbnNlLiBUaGUgcXVlc3Rpb24gaXM6IHNoYWxsIHdlIGtlZXAgaXQgc2VwYXJhdGVkDQphcyBp dCBpcyB0b2RheSBhcyAiTElTUCIgYW5kICJWeExBTiIgb3IgY29tYmluZSB0aGUgKGV4cGVuc2l2 ZSkgbXVsdGlwbGUgZGF0YQ0KcGxhbmVzIGludG8gb25lIFZ4TEFOLWdwZS4NCg0KDQpSZWdhcmRz LCBNYXJjDQoNCg0KDQoNCg0KT24gV2VkLCAzMCBKdWwgMjAxNCAwMzoxNToxOSArMDAwMCwgSGFv d2VpZ3VvIHdyb3RlOg0KPiBIaSBEaW5vLA0KPiBWWExBTiBjYW4gdXNlIGEgdW5pZmllZCBlbmNh cHN1bGF0aW9uIHRvIHJlYWxpemUgYm90aCBpbnRyYS1zdWJuZXQgbGF5ZXIgMg0KPiB0cmFmZmlj IGZvcndhcmRpbmcgYW5kIGludGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9yd2FyZGluZyBh dCB0aGUgc2FtZQ0KPiB0aW1lLCBpbm5lciBkZXN0aW5hdGlvbiBNQUMgaXMgdXNlZCB0byBkaWZm ZXJlbmNpYXRlIGxheWVyIDIgdHJhZmZpYyBmcm9tDQo+IGxheWVyIDMgdHJhZmZpYy4NCj4gTElT UCB1c2VzIHR3byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMgZm9yIGludHJhLXN1Ym5ldCBsYXll ciAyIHRyYWZmaWMNCj4gZm9yd2FyZGluZyBhbmQgaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZp YyBmb3J3YXJkaW5nLCBVRFAgcG9ydCBpcyB1c2VkIHRvDQo+IGRpZmZlcmVuY2lhdGUgbGF5ZXIg MiB0cmFmZmljIGZyb20gbGF5ZXIgMyB0cmFmZmljLg0KPiBGcm9tIHRoZW9yZXRpY2FsIHBlcnNw ZWN0aXZlLCAgYm90aCB0aGUgdHdvIHNvbHV0aW9ucyBhcmUgYXBwbGljYWJsZS4gRnJvbQ0KPiBj b21tZXJjaWFsIHVzZSBwZXJzcGVjdGl2ZSwgdGhlIGZvcm1lcih1bmlmaWVkIGVuY2FwIGZvciBi b3RoIGxheWVyIDIgYW5kDQo+IGxheWVyIDMpIHNlZW1zIHRvIGJlIG1vcmUgcG9wdWxhciBjdXJy ZW50bHkuDQo+IFRoYW5rcw0KPiB3ZWlndW8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiC3orz+yMs6IERpbm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lAZ21haWwu Y29tXQ0KPiC3osvNyrG85DogMjAxNMTqN9TCMjnI1SAyMDoxOA0KPiDK1bz+yMs6IEhhb3dlaWd1 bw0KPiCzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0 IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+INb3zOI6IFJlOiC08Li0OiBbbnZvM10gQ29tbWVudHMgb24N Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQo+ DQo+IEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nIGJ1dCBpdCBjb21lcyBkb3duIHRv IHdoYXQgdGhlIGVuY2Fwc3VsYXRvcg0KPiBpcyBlbmNhcHN1bGF0aW5nLiBJZiB0aGUgcGFja2V0 IGl0IGlzIGVuY2Fwc3VsYXRpbmcgaXMgYW4gTDIgZnJhbWUgdGhlbiB0aGUNCj4gZW5jYXBzdWxh dG9yIGlzIHN1cHBvcnRpbmcgYSBsYXllci0yIG92ZXJsYXkgc2VydmljZS4gT3RoZXJ3aXNlIGl0 IGlzIGEgYQ0KPiBsYXllci0zIG92ZXJsYXkgc2VydmljZS4NCj4NCj4gSWYgdGhlIGRlc3QgTUFD IElzIHRvIHRoZSBlbmNhcHN1bGF0b3IgdGhhdCBNQUMgaGVhZGVyIGlzIHN0cmlwcGVkIGJlZm9y ZSBhDQo+IGxheWVyLTMgZm9yd2FyZGluZyBkZWNpc2lvbiBpcyBtYWRlLiBUaGVuLCBhdCB3aGlj aCB0aW1lIHRoZSBwYWNrZXQgaXMNCj4gZm9yd2FyZGVkIG5hdGl2ZWx5IG9yIGVuY2Fwc3VsYXRl ZC4NCj4NCj4gSWYgdGhlIGRlc3QgTUFDIGlzIG5vdCB0aGUgZW5jYXBzdWxhdG9yJ3MgYWRkcmVz cywgdGhlbiB0aGUgTUFDIGhlYWRlcg0KPiBzdGF5cyB3aXRoIHRoZSBwYWNrZXQvZnJhbWUgYW5k IHRoZW4gZW5jYXBzdWxhdGVkLg0KPg0KPiBUaGUgZm9ybWVyIGlzIGEgbGF5ZXItMyBvdmVybGF5 IGFuZCB0aGUgbGF0dGVyIGlzIGEgbGF5ZXItMiBvdmVybGF5IHdoZXJlDQo+IGJvdGggY2FuIGJl IHN1cHBvcnRlZCBhdCB0aGUgc2FtZSB0aW1lIGluIG9uZSBlbmNhcHN1bGF0b3IgZGV2aWNlLg0K Pg0KPiBUaGUgZm9ybWVyIGlzIExJU1AgZW5jYXBzdWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBW WExBTiBlbmNhcHN1bGF0aW9uLg0KPg0KPiBXaXRoIFZYTEFOLUdQRSBib3RoIGNhc2VzIGNhbiBi ZSBzdXBwb3J0ZWQgKGFuZCBtb3N0IGltcG9ydGFudGx5IHdpdGggYQ0KPiBzaW5nbGUgdW5pZmll ZCBjb250cm9sLXBsYW5lKS4NCj4NCj4gU28gSSBiZWxpZXZlIFZYTEFOLUdQRSBjb3VsZCBiZSB1 c2VmdWwgeWV0IHJlZHVuZGFudCBidXQgTElTUCByZXF1aXJlcyBubw0KPiBjaGFuZ2VzIChpZiBM SVNQIHN1cHBvcnRzICBMMiB3aGljaCBpcyBkb2N1bWVudGVkIGluDQo+IGRyYWZ0LXNtaXRoLWxp c3AtbGF5ZXItMiB1c2luZyBhIGRpZmZlcmVudCBwb3J0IG51bWJlcikuDQo+DQo+IERpbm8NCj4N Cj4+IE9uIEp1bCAyOSwgMjAxNCwgYXQgMzo1OCBBTSwgSGFvd2VpZ3VvIDxoYW93ZWlndW9AaHVh d2VpLmNvbT4gd3JvdGU6DQo+Pg0KPj4gSGkgRGlubywNCj4+IFRoYW5rcyBmb3IgeW91ciBkZXRh aWwgY29tbWVudHMuICBBcyBmb3IgY3VycmVudCBWWExBTiBlbmNhcHN1bGF0aW9uLCBwbHMNCj4+ IHNlZSBteSBjb21tZW50cyBpbmxpbmUgd2l0aCBbd2VpZ3VvXSBiZWxvdy4NCj4+DQo+PiBUaGVy ZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2gg aXMgY2FsbGVkDQo+PiBWWExBTi1HUEUpIHNvIGl0IGNhbiBzdXBwb3J0LCBtb3N0IGltcG9ydGFu dGx5IE5TSC4gVGhhdCBjaGFuZ2UgYWxzbyBnaXZlcw0KPj4gVlhMQU4gdG8gc3VwcG9ydCBlbmNh cHN1bGF0aW5nIGxheWVyLTIgSVB2NCBhbmQgSVB2Niwgd2hpY2ggaXMgZHVwbGljYXRlDQo+PiBm dW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUgc28gc2ltaWxhciwgaXQg cmVhbGx5IGRvZW5zJ3QNCj4+IG1hdHRlci4NCj4+DQo+PiBbd2VpZ3VvXTogWWVzLCBhbiBuZXcg ZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQNCj4+IE5T SC4gQnV0IGFzIGZvciBJUHY0IGFuZCBJUHY2LCBpIHRoaW5rIGN1cnJlbnQgVlhMQU4gYWxyZWFk eSBzdXBwb3J0ZWQuDQo+PiBGb3IgdGhlIGxheWVyIDMgaW50ZXItc3VibmV0IHRyYWZmaWMgZnJv bSBOVkUxIHRvIE5WRTIsIGlubmVyIGRlc3RpbmF0aW9uDQo+PiBNQUMgaXMgdGhlIGdhdGV3YXkg aW50ZXJmYWNlIE1BQyBhdCBOVkUyLiAgRm9yIHRoZSBsYXllciAyIGludHJhLXN1Ym5ldA0KPj4g dHJhZmZpYyBmcm9tIE5WRTEgdG8gTlZFMiwgIGlubmVyIGRlc3RpbmF0aW9uIE1BQyBpcyB0aGUg ZGVzdGluYXRpb24gVFMncw0KPj4gTUFDLiBXaGVuIE5WRTIgcmVjZWl2ZXMgVlhMQU4gZW5jYXBz dWxhdGVkIHRyYWZmaWMgZnJvbSBOVkUxLCBpbm5lcg0KPj4gZGVzdGluYXRpb24gTUFDIGNhbiBi ZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgbGF5ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMw0KPj4g dHJhZmZpYy4gVlhMQU4gZGlzdHJpYnV0ZWQgbGF5ZXIgMyBnYXRld2F5IGNhbiBiZSByZWFsaXpl ZCB0aHJvdWdoIHRoZQ0KPj4gbWVjaGFuaXNtLCBOVkUgY2FuIGZvcndhcmQgYm90aCBpbnRyYS1z dWJuZXQgbGF5ZXIgMiB0cmFmZmljIGFuZA0KPj4gaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZp YyBhdCB0aGUgc2FtZSB0aW1lLg0KPj4NCj4+IFRoYW5rcw0KPj4gd2VpZ3VvDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiC3orz+yMs6IERpbm8gRmFyaW5h Y2NpIFtmYXJpbmFjY2lAZ21haWwuY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjI6 MTcNCj4+IMrVvP7IyzogSGFvd2VpZ3VvDQo+PiCzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0 Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+PiDW98ziOiBSZTog W252bzNdIENvbW1lbnRzIG9uDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1x dWlubi12eGxhbi1ncGUtMDMNCj4+DQo+Pj4gSGkgRGlubywNCj4+PiBTb3JyeSwgaSBtaXN1bmRl cnN0b29kIHlvdS4gSSB0aGluayBWWExBTi1HUEUgY2FuIGRlZmluZSBhIG5ldyBVRFAgcG9ydA0K Pj4+IGFuZCBhIG5ldyBkYXRhIGZvcm1hdCwgUCBiaXQNCj4+DQo+PiBObyB3b3JyaWVzLg0KPj4N Cj4+PiBpbiBWWExBTi1HUEUgc2VlbXMgdG8gaGF2ZSBubyBhbnkgdmFsdWUuIEFzIGZvciBiYXNp YyBpbnRlci1zdWJuZXQgbGF5ZXINCj4+PiAzIGNvbW11bmljYXRpb24gYW5kIGludHJhLXN1Ym5l dCBsYXllciAyIGNvbW11bmljYXRpb24gYmV0d2VlbiBOVkVzLA0KPj4+IGN1cnJlbnQgTlZHUkUs IFZYTEFOIGFuZCBMSVNQIGhhdmUgYWxyZWFkeSBzdXBwb3J0ZWQsDQo+Pg0KPj4gVlhMQU4gc3Vw cG9ydHMgTDIgb3ZlcmxheXMgc2luY2UgaXRzIGdvYWwgaXMgdG8gZXh0ZW5kIHN1Ym5ldHMuIExJ U1ANCj4+IHN1cHBvcnRzIEwzIG92ZXJsYXlzIHNvIGl0IGFzc3VtZXMgc3VibmV0cyBhcmUgbG9j YWwgKHRvIHRoZSB4VFIpIGp1c3QNCj4+IGxpa2UgaW4gYSByb3V0ZWQgbmV0d29yay4gTlZHUkUg Y2FuIGJlIGEgY29tYm8uDQo+Pg0KPj4+IE5WR1JFLFZYTEFOLExJU1AgYW5kIFZYTEFOLUdQRSBj YW4gYmUgaHlicmlkIHVzZWQgdG8gZm9ybSBhIE5WTzMgbmV0d29yaw0KPj4+IGlmIG9ubHkgYmFz aWMgbGF5ZXIgMyBhbmQNCj4+DQo+PiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBl bmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggaXMgY2FsbGVkDQo+PiBWWExBTi1HUEUpIHNvIGl0 IGNhbiBzdXBwb3J0LCBtb3N0IGltcG9ydGFudGx5IE5TSC4gVGhhdCBjaGFuZ2UgYWxzbyBnaXZl cw0KPj4gVlhMQU4gdG8gc3VwcG9ydCBlbmNhcHN1bGF0aW5nIGxheWVyLTIgSVB2NCBhbmQgSVB2 Niwgd2hpY2ggaXMgZHVwbGljYXRlDQo+PiBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUg aGVhZGVycyBhcmUgc28gc2ltaWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QNCj4+IG1hdHRlci4NCj4+ DQo+PiBIb3dldmVyLCB0aGUgUC1iaXQgaXMgbm90IG5lZWRlZCBmb3IgYW55dGhpbmcgbmV3IGlu IExJU1AgYW5kIHRoZSBPQU0tYml0DQo+PiBpcyBub3QgbmVlZGVkIGluIExJU1Agc2luY2UgTElT UCBoYXMgZGlmZmVyZW50IFVEUCBwb3J0IG51bWJlciAoNDM0MikgZm9yDQo+PiBjb250cm9sLXBh Y2tldHMuIFZYTEFOIGRvZXMgbm90IGhhdmUgYSB3ZWxsIGRlZmluZWQgY29udHJvbCBwcm90b2Nv bCBzbw0KPj4gdGhlIGRhdGEtcGxhbmUgaGFzIHRvIGVzY2FwZSBvdXQgY29udHJvbC1wbGFuZSBw YWtjZXRzIHdoZXJlIHRoZSBmaXJzdCBvbmUNCj4+IGlzIHRoaXMgbmV3IE9BTSBtZXNzYWdlLg0K Pj4NCj4+PiBsYXllciAyIGZvcndhcmRpbmcgcHJvY2VzcyBleGlzdHMuIEFzIGZvciBzb21lIGV4 dHJhIGZ1bmN0aW9ucyBvZiBPQU0sDQo+Pj4gc2VydmljZSBjaGFpbmluZyxhbmQgZXRjLCAgb25s eSBWWExBTi1HUEUgY2FuIHN1cHBvcnQsIHB1cmUgVlhMQU4tR1BFDQo+Pj4gbmV0d29yayBzaG91 bGQgYmUgdXNlZCBpbiB0aGVzZSBjYXNlcy4NCj4+PiBUaGFua3MNCj4+PiB3ZWlndW8NCj4+DQo+ PiBSaWdodCwgYWdyZWUuDQo+Pg0KPj4gRGlubw0KPj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ILeivP7IyzogRGlubyBGYXJpbmFj Y2kgW2ZhcmluYWNjaUBnbWFpbC5jb21dDQo+Pj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4yNUgMjE6 MTUNCj4+PiDK1bz+yMs6IEhhb3dlaWd1bw0KPj4+ILOty806IFRvbSBIZXJiZXJ0OyBEYXZpZCBN ZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCj4+PiDW98ziOiBS ZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uDQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcXVpbm4tdnhsYW4tZ3BlLTAzDQo+Pj4NCj4+Pj4gT24gSnVsIDI4LCAyMDE0LCBh dCA3OjI0IEFNLCBIYW93ZWlndW8gPGhhb3dlaWd1b0BodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4N Cj4+Pj4gQWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaSBhbHNvIGFncmVlIHdpdGggRGlu by4gVlhMQU4tR1BFIHNob3VsZA0KPj4+PiBmb2N1cyBvbiAgdGhlIFZYTEFOLUdQRSBoZWFkZXIg YW5kIHJlcXVpcmVzIHRoZSBhc3NpZ25tZW50IG9mIGEgbmV3IFVEUA0KPj4+PiBwb3J0LCB0aGUg ZGF0YSBmb3JtYXQgZG9uJ3QgbmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdp dGgNCj4+Pj4gVlhMQU4gaGVhZGVyLiBJDQo+Pj4NCj4+PiBJIHdhbnQgdG8gbWFrZSBpdCBjbGVh ciB0aGF0IHN1cHBvcnRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyB2ZXJ5DQo+Pj4gaW1w b3J0YW50IHNpbmNlIFZYTEFOLXBvcnQtNDc4OSBpcyBzdXBwb3J0ZWQgaW4gdmFyaW91cyBjaGlw cyBhbHJlYWR5Lg0KPj4+DQo+Pj4gRGlubw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw== From nobody Wed Jul 30 04:57:32 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4A1B278F; Wed, 30 Jul 2014 04:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOz3g2_ftzUf; Wed, 30 Jul 2014 04:57:28 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483851A0378; Wed, 30 Jul 2014 04:57:28 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so1345073pdj.12 for ; Wed, 30 Jul 2014 04:57: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=wovimTiHtBZilX1NHNPfw7XevngOp32BCbUQNhW8hxU=; b=KEafjTEJFTcn8SLw8kSjoqTBzPLZgp9VAxnIzm59yDd6N09tUITT8Y642GsuySyPy5 JozP0dwnGubrmjREpAAakSRbnKJ/qnhP2C6+OIQ0aTWEZL+zGkK6tsp/4RiavqANG/Jp 14cvJzyqpuAvaiRGyKFjVLYhRUg5DDxFiRAIVZ7icncyHsbv+omfsrOMOSObAwer7uRu 1sMCJpih/pUcEeCVClDFLWWs6v8Mn9l24K8dducyi/gnLNQ3ZGu96DV359Lo5qLTLxLl 4UBS/ZiyvDSwuC44ofjzD1kD0a0HSkixZN9sMw4Gyu3nJHflG9yo3krydSH29OhNH6nj xzNw== X-Received: by 10.70.60.226 with SMTP id k2mr4024217pdr.130.1406721447940; Wed, 30 Jul 2014 04:57:27 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id d3sm3176732pdi.49.2014.07.30.04.57.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 04:57:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 30 Jul 2014 04:57:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Azehe8ocNUdtzj0FMSvFwt2z8ag Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] =?utf-8?b?562U5aSNOiDnrZTlpI06IFtudm8zXSBDb21tZW50cyBvbiBo?= =?utf-8?q?ttp=3A//tools=2Eietf=2Eorg/html/draft-quinn-vxlan-gpe-03?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:57:30 -0000 A minor correction, LISP does have a unified encapsulation where the packet d= emux function, that has been defined for a few years, is done with UDP ports= . As for VXLAN, the packet demux, has been recently introduced, is done with= the P-bit.=20 Dino > On Jul 29, 2014, at 8:15 PM, Haoweiguo wrote: >=20 > Hi Dino, > VXLAN can use a unified encapsulation to realize both intra-subnet layer 2= traffic forwarding and inter-subnet layer 3 traffic forwarding at the same t= ime, inner destination MAC is used to differenciate layer 2 traffic from lay= er 3 traffic.=20 > LISP uses two different encapsulations for intra-subnet layer 2 traffic fo= rwarding and inter-subnet layer 3 traffic forwarding, UDP port is used to di= fferenciate layer 2 traffic from layer 3 traffic. > =46rom theoretical perspective, both the two solutions are applicable. =46rom= commercial use perspective, the former(unified encap for both layer 2 and l= ayer 3) seems to be more popular currently. > Thanks > weiguo > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8829=E6=97=A5 2= 0:18 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo > =E6=8A=84=E9=80=81: David Melman; nvo3@ietf.org; LISP mailing list list; T= om Herbert > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [nvo3] Comments on http://tool= s.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 > I understand what you are saying but it comes down to what the encapsulato= r is encapsulating. If the packet it is encapsulating is an L2 frame then th= e encapsulator is supporting a layer-2 overlay service. Otherwise it is a a l= ayer-3 overlay service. >=20 > If the dest MAC Is to the encapsulator that MAC header is stripped before a= layer-3 forwarding decision is made. Then, at which time the packet is forw= arded natively or encapsulated. >=20 > If the dest MAC is not the encapsulator's address, then the MAC header sta= ys with the packet/frame and then encapsulated. >=20 > The former is a layer-3 overlay and the latter is a layer-2 overlay where b= oth can be supported at the same time in one encapsulator device. >=20 > The former is LISP encapsulation and the latter is VXLAN encapsulation. >=20 > With VXLAN-GPE both cases can be supported (and most importantly with a si= ngle unified control-plane). >=20 > So I believe VXLAN-GPE could be useful yet redundant but LISP requires no c= hanges (if LISP supports L2 which is documented in draft-smith-lisp-layer-2= using a different port number). >=20 > Dino >=20 >> On Jul 29, 2014, at 3:58 AM, Haoweiguo wrote: >>=20 >> Hi Dino, >> Thanks for your detail comments. As for current VXLAN encapsulation, pls= see my comments inline with [weiguo] below. >>=20 >> There is motivation to extend an encapsulation header (which is called VX= LAN-GPE) so it can support, most importantly NSH. That change also gives VXL= AN to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functi= onality of LISP. But the headers are so similar, it really doens't matter. >>=20 >> [weiguo]: Yes, an new encapsulation header should be extended to support N= SH. But as for IPv4 and IPv6, i think current VXLAN already supported. For t= he layer 3 inter-subnet traffic from NVE1 to NVE2, inner destination MAC is t= he gateway interface MAC at NVE2. For the layer 2 intra-subnet traffic from= NVE1 to NVE2, inner destination MAC is the destination TS's MAC. When NVE2= receives VXLAN encapsulated traffic from NVE1, inner destination MAC can be= used to differentiate layer 2 traffic from layer 3 traffic. VXLAN distribut= ed layer 3 gateway can be realized through the mechanism, NVE can forward bo= th intra-subnet layer 2 traffic and inter-subnet layer 3 traffic at the same= time. >>=20 >> Thanks >> weiguo >> ________________________________________ >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5 2= 2:17 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo >> =E6=8A=84=E9=80=81: David Melman; nvo3@ietf.org; LISP mailing list list; T= om Herbert >> =E4=B8=BB=E9=A2=98: Re: [nvo3] Comments on http://tools.ietf.org/html/dra= ft-quinn-vxlan-gpe-03 >>=20 >>> Hi Dino, >>> Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port a= nd a new data format, P bit >>=20 >> No worries. >>=20 >>> in VXLAN-GPE seems to have no any value. As for basic inter-subnet layer= 3 communication and intra-subnet layer 2 communication between NVEs, curren= t NVGRE, VXLAN and LISP have already supported, >>=20 >> VXLAN supports L2 overlays since its goal is to extend subnets. LISP supp= orts L3 overlays so it assumes subnets are local (to the xTR) just like in a= routed network. NVGRE can be a combo. >>=20 >>> NVGRE,VXLAN,LISP and VXLAN-GPE can be hybrid used to form a NVO3 network= if only basic layer 3 and >>=20 >> There is motivation to extend an encapsulation header (which is called VX= LAN-GPE) so it can support, most importantly NSH. That change also gives VXL= AN to support encapsulating layer-2 IPv4 and IPv6, which is duplicate functi= onality of LISP. But the headers are so similar, it really doens't matter. >>=20 >> However, the P-bit is not needed for anything new in LISP and the OAM-bit= is not needed in LISP since LISP has different UDP port number (4342) for c= ontrol-packets. VXLAN does not have a well defined control protocol so the d= ata-plane has to escape out control-plane pakcets where the first one is thi= s new OAM message. >>=20 >>> layer 2 forwarding process exists. As for some extra functions of OAM, s= ervice chaining,and etc, only VXLAN-GPE can support, pure VXLAN-GPE network= should be used in these cases. >>> Thanks >>> weiguo >>=20 >> Right, agree. >>=20 >> Dino >>=20 >>>=20 >>>=20 >>> ________________________________________ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Dino Farinacci [farinacci@gmail.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8828=E6=97=A5= 21:15 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo >>> =E6=8A=84=E9=80=81: Tom Herbert; David Melman; nvo3@ietf.org; LISP maili= ng list list >>> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [nvo3] Comments on http://to= ols.ietf.org/html/draft-quinn-vxlan-gpe-03 >>>=20 >>>> On Jul 28, 2014, at 7:24 AM, Haoweiguo wrote: >>>>=20 >>>> About backward compatibility, i also agree with Dino. VXLAN-GPE should f= ocus on the VXLAN-GPE header and requires the assignment of a new UDP port,= the data format don't need consider backward compatibility with VXLAN heade= r. I >>>=20 >>> I want to make it clear that supporting backward compatibility is very i= mportant since VXLAN-port-4789 is supported in various chips already. >>>=20 >>> Dino From nobody Wed Jul 30 05:00:52 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148D41B278F; Wed, 30 Jul 2014 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wk-2GGBPu0V; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC551A0378; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so1340438pdj.16 for ; Wed, 30 Jul 2014 05:00:42 -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=IstDw4WBae0Dhkta/1pLnXkw0VdMyGDaXZYCYSAi5BI=; b=m2oa44l6hk2Nl7MbeDd+57cd8pk1dQ7nH1PqJ85wvE3EI+8DIOuFVFCgni50cdYKvZ L/RkkPhrsrnzsCE9uEp+Wv3/x0/he0zZn4bCfRyM+MtXR+9vBL5w8WfQey5UGYZxgLu9 7jRgZT3JyKnYTimDLifhhRPdo4BxwQg+rQOJLVtMVkzAMUOEncRqdbYmn4sr8Dp50CDZ UUBXuiGj6pTR0XjiVUXt5u+ViFo1jN/oly1UkINIqgmT8sXIc4XyiHAzblcV2iDlv9Po qZj2vN1dl3pWIyGeTqc0XjGrPci7vdH6bO29knNA7pE2yqW927UUMOqU+p2Agkvh0QBa DtIA== X-Received: by 10.66.163.226 with SMTP id yl2mr3891472pab.73.1406721642057; Wed, 30 Jul 2014 05:00:42 -0700 (PDT) Received: from [192.168.1.34] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id z4sm3202999pdb.18.2014.07.30.05.00.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 05:00:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 30 Jul 2014 05:00:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> <20140729234019087723.ceceb885@sniff.de> To: Haoweiguo Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/QiwBvlnPky8_NIId3Gshv2JD78g Cc: Tom Herbert , David Melman , LISP mailing list list , "nvo3@ietf.org" Subject: Re: [lisp] =?utf-8?b?562U5aSNOiBbbnZvM10g562U5aSNOiDnrZTlpI06ICBDb21t?= =?utf-8?q?ents_on_http=3A//tools=2Eietf=2Eorg/html/draft-quinn-vxlan-gpe-?= =?utf-8?q?03?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:00:47 -0000 > On Jul 30, 2014, at 2:29 AM, Haoweiguo wrote: >=20 > VXLAN-GPE have next protocol field, so it can combine multiple data planes= into one VXLAN-gpe. Currently inner destination MAC can be used to distingu= ish layer 2 and layer 3 traffic at egress NVE. You can do what you say today with VXLAN. You don't need GPE for this. The d= emux is just in the ethertype field if the inner MAC header.=20 Dino=20= From nobody Wed Jul 30 07:20:09 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD671A00BA; Wed, 30 Jul 2014 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.999 X-Spam-Level: **** X-Spam-Status: No, score=4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk9L795JeHyU; Wed, 30 Jul 2014 07:19:55 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AD1A00AB; Wed, 30 Jul 2014 07:19:54 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 80E3E2AA0F; Wed, 30 Jul 2014 14:19:51 +0000 (GMT) Date: Wed, 30 Jul 2014 07:19:55 -0700 From: Marc Binderberger To: Haoweiguo Message-ID: <20140730071955406839.4eeb788e@sniff.de> In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>

<650F5E9B-1C47-45F3-AF6A-38B4961F9A12@gmail.com> <618AB825-CE3B-44D3-A011-2C1E15C051E9@gmail.com> <00F5B735-18AD-41CA-A651-13BF80815BD2@gmail.com> <20140729234019087723.ceceb885@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/D6zhOEl76poFRF3z_YCgJJD4ikw Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] =?gb2312?b?W252bzNdILTwuLQ6ICC08Li0OiC08Li0OiBDb21tZW50?= =?gb2312?b?cyBvbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi12?= =?gb2312?b?eGxhbi1ncGUtMDM=?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:19:57 -0000 SGVsbG8gV2VpZ3VvLA0KDQo+IFZYTEFOLUdQRSBoYXZlIG5leHQgcHJvdG9jb2wgZmllbGQs IHNvIGl0IGNhbiBjb21iaW5lIG11bHRpcGxlIGRhdGEgcGxhbmVzIA0KPiBpbnRvIG9uZSBW WExBTi1ncGUuDQoNCnNvIHlvdSBhcmUgZmluZSB3aXRoIHRoZSBWeExBTi1ncGUgbGF5b3V0 IHRoZW4/IE9rYXksIEkgbWlzdW5kZXJzdG9vZCB0aGlzLg0KDQo+IEN1cnJlbnRseSBpbm5l ciBkZXN0aW5hdGlvbiBNQUMgY2FuIGJlIHVzZWQgdG8gDQo+IGRpc3Rpbmd1aXNoIGxheWVy IDIgYW5kIGxheWVyIDMgdHJhZmZpYyBhdCBlZ3Jlc3MgTlZFLg0KDQphcyBJIHNhaWQgSSBz ZWUgYSBzdWJ0bGUgZGlmZmVyZW5jZSBoZXJlIGFuZCB3b3VsZCBzYXkgVnhMQU4gaXMgZG9p bmcgYSANCmxheWVyLTIgb3BlcmF0aW9uLiBOZXZlcnRoZWxlc3MsIGlmIHlvdXIgZW5jYXBz dWxhdGlvbi9kZWNhcHN1bGF0aW9uIG5ldHdvcmsgDQplbGVtZW50cyB1bmRlcnN0YW5kIHRo aXMgbGF5ZXItMiBhc3BlY3QsIGFyZSBjYXBhYmxlIHRvIGFkZCBFdGhlcm5ldCBoZWFkZXIs IA0KVnhMQU4gc2hpbSBhbmQgb3V0ZXIgSVAgaGVhZGVyIG9udG8gdGhlIGlubmVyIElQIHBh Y2tldCBldGMuLCB0aGVuIHllcywgeW91IA0KY291bGQgdHJhbnNwb3J0IGxheWVyLTMgd2l0 aCBWeExBTi4NCg0KDQpSZWdhcmRzLCBNYXJjDQoNCg0KDQo+IFRoYW5rcw0KPiB3ZWlndW8N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiC3orz+yMs6 IE1hcmMgQmluZGVyYmVyZ2VyIFttYXJjQHNuaWZmLmRlXQ0KPiC3osvNyrG85DogMjAxNMTq N9TCMzDI1SAxNDo0MA0KPiDK1bz+yMs6IEhhb3dlaWd1bw0KPiCzrcvNOiBEaW5vIEZhcmlu YWNjaTsgRGF2aWQgTWVsbWFuOyBudm8zQGlldGYub3JnOyBMSVNQIG1haWxpbmcgbGlzdCBs aXN0OyANCj4gVG9tIEhlcmJlcnQNCj4g1vfM4jogUmU6IFtudm8zXSC08Li0OiC08Li0OiAg Q29tbWVudHMgb24gDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5u LXZ4bGFuLWdwZS0wMw0KPiANCj4gSGVsbG8gV2VpZ3VvLA0KPiANCj4gSSB3b3VsZCBzYXkg dGhlcmUgaXMgYSBkaWZmZXJlbmNlIGlmIHlvdXIgImxheWVyLTMiIHNlcnZpY2UgaXMgYWN0 dWFsbHkgYQ0KPiBsYXllci0yIEV0aGVybmV0IGZyYW1lIHdpdGggdGhlIGRlc3RpbmF0aW9u IE1BQyBvZiB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldA0KPiBiZWluZyBpZGVudGljYWwgd2l0 aCB0aGUgTUFDIG9mIHRoZSBkZWNhcHN1bGF0aW5nIHN5c3RlbSwgY29tcGFyZWQgdG8gYQ0K PiBsYXllci0zIHNlcnZpY2Ugd2hlcmUgeW91ciB3aG9sZSBwcm9jZXNzaW5nIHN0YXlzIHNv bGVseSBpbiB0aGUgbGF5ZXItMywgbm8NCj4gTUFDIGludm9sdmVkLg0KPiANCj4gSWYgSSB3 YW50IHRvIGRlZmluZSBhIGxheWVyLTMgZW5jYXBzdWxhdGlvbiAobGlrZSBMSVNQLCBsaWtl IHRoZSBwcm9wb3NlZA0KPiBWeExBTi1ncGUgd2l0aCBJUHY0L3Y2IGFzIHByb3RvY29sKSB0 aGVuIGhhdmluZyBhbnkgbGF5ZXItMiBpbiB0aGUgcHJvY2Vzcw0KPiBzZWVtcyBhIGJpdCAi b2RkIi4gV29yc2UsIHRoZSBpbnZvbHZlZCBzeXN0ZW1zIG1heSBub3QgaGF2ZSB0aGlzIGxh eWVyLTINCj4gbG9naWMuIExJU1AgZm9yIGV4YW1wbGUgaXMgb2Z0ZW4gdXNlZCBpbiB0aGUg V0FOLCBldmVuIHdoZW4gc29tZQ0KPiBlbmNhcHN1bGF0b3IvZGVjYXBzdWxhdG9yIGFyZSBE QyBzd2l0Y2hlcy4gU29tZSBvZiB0aGVzZSBXQU4gc3lzdGVtcyBtYXkgYmUNCj4gcHVyZSBJ UHY0L3Y2IHJvdXRlcnMuDQo+IA0KPiANCj4gSW4gb3RoZXIgd29yZHM6IGhhdmluZyBib3Ro IGEgbGF5ZXItMiAoVnhMQU4pIGFuZCBhIGxheWVyLTMgKExJU1ApDQo+IGVuY2Fwc3VsYXRp b24gbWFrZXMgZ29vZCBzZW5zZS4gVGhlIHF1ZXN0aW9uIGlzOiBzaGFsbCB3ZSBrZWVwIGl0 IHNlcGFyYXRlZA0KPiBhcyBpdCBpcyB0b2RheSBhcyAiTElTUCIgYW5kICJWeExBTiIgb3Ig Y29tYmluZSB0aGUgKGV4cGVuc2l2ZSkgbXVsdGlwbGUgDQo+IGRhdGENCj4gcGxhbmVzIGlu dG8gb25lIFZ4TEFOLWdwZS4NCj4gDQo+IA0KPiBSZWdhcmRzLCBNYXJjDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gT24gV2VkLCAzMCBKdWwgMjAxNCAwMzoxNToxOSArMDAwMCwgSGFvd2Vp Z3VvIHdyb3RlOg0KPj4gSGkgRGlubywNCj4+IFZYTEFOIGNhbiB1c2UgYSB1bmlmaWVkIGVu Y2Fwc3VsYXRpb24gdG8gcmVhbGl6ZSBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyDQo+PiB0 cmFmZmljIGZvcndhcmRpbmcgYW5kIGludGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9y d2FyZGluZyBhdCB0aGUgc2FtZQ0KPj4gdGltZSwgaW5uZXIgZGVzdGluYXRpb24gTUFDIGlz IHVzZWQgdG8gZGlmZmVyZW5jaWF0ZSBsYXllciAyIHRyYWZmaWMgZnJvbQ0KPj4gbGF5ZXIg MyB0cmFmZmljLg0KPj4gTElTUCB1c2VzIHR3byBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMg Zm9yIGludHJhLXN1Ym5ldCBsYXllciAyIHRyYWZmaWMNCj4+IGZvcndhcmRpbmcgYW5kIGlu dGVyLXN1Ym5ldCBsYXllciAzIHRyYWZmaWMgZm9yd2FyZGluZywgVURQIHBvcnQgaXMgdXNl ZCB0bw0KPj4gZGlmZmVyZW5jaWF0ZSBsYXllciAyIHRyYWZmaWMgZnJvbSBsYXllciAzIHRy YWZmaWMuDQo+PiBGcm9tIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLCAgYm90aCB0aGUgdHdv IHNvbHV0aW9ucyBhcmUgYXBwbGljYWJsZS4gRnJvbQ0KPj4gY29tbWVyY2lhbCB1c2UgcGVy c3BlY3RpdmUsIHRoZSBmb3JtZXIodW5pZmllZCBlbmNhcCBmb3IgYm90aCBsYXllciAyIGFu ZA0KPj4gbGF5ZXIgMykgc2VlbXMgdG8gYmUgbW9yZSBwb3B1bGFyIGN1cnJlbnRseS4NCj4+ IFRoYW5rcw0KPj4gd2VpZ3VvDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiC3orz+yMs6IERpbm8gRmFyaW5hY2NpIFtmYXJpbmFjY2lAZ21haWwu Y29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI5yNUgMjA6MTgNCj4+IMrVvP7IyzogSGFv d2VpZ3VvDQo+PiCzrcvNOiBEYXZpZCBNZWxtYW47IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFp bGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+PiDW98ziOiBSZTogtPC4tDogW252bzNd IENvbW1lbnRzIG9uDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlu bi12eGxhbi1ncGUtMDMNCj4+IA0KPj4gSSB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBzYXlp bmcgYnV0IGl0IGNvbWVzIGRvd24gdG8gd2hhdCB0aGUgZW5jYXBzdWxhdG9yDQo+PiBpcyBl bmNhcHN1bGF0aW5nLiBJZiB0aGUgcGFja2V0IGl0IGlzIGVuY2Fwc3VsYXRpbmcgaXMgYW4g TDIgZnJhbWUgdGhlbiB0aGUNCj4+IGVuY2Fwc3VsYXRvciBpcyBzdXBwb3J0aW5nIGEgbGF5 ZXItMiBvdmVybGF5IHNlcnZpY2UuIE90aGVyd2lzZSBpdCBpcyBhIGENCj4+IGxheWVyLTMg b3ZlcmxheSBzZXJ2aWNlLg0KPj4gDQo+PiBJZiB0aGUgZGVzdCBNQUMgSXMgdG8gdGhlIGVu Y2Fwc3VsYXRvciB0aGF0IE1BQyBoZWFkZXIgaXMgc3RyaXBwZWQgYmVmb3JlIGENCj4+IGxh eWVyLTMgZm9yd2FyZGluZyBkZWNpc2lvbiBpcyBtYWRlLiBUaGVuLCBhdCB3aGljaCB0aW1l IHRoZSBwYWNrZXQgaXMNCj4+IGZvcndhcmRlZCBuYXRpdmVseSBvciBlbmNhcHN1bGF0ZWQu DQo+PiANCj4+IElmIHRoZSBkZXN0IE1BQyBpcyBub3QgdGhlIGVuY2Fwc3VsYXRvcidzIGFk ZHJlc3MsIHRoZW4gdGhlIE1BQyBoZWFkZXINCj4+IHN0YXlzIHdpdGggdGhlIHBhY2tldC9m cmFtZSBhbmQgdGhlbiBlbmNhcHN1bGF0ZWQuDQo+PiANCj4+IFRoZSBmb3JtZXIgaXMgYSBs YXllci0zIG92ZXJsYXkgYW5kIHRoZSBsYXR0ZXIgaXMgYSBsYXllci0yIG92ZXJsYXkgd2hl cmUNCj4+IGJvdGggY2FuIGJlIHN1cHBvcnRlZCBhdCB0aGUgc2FtZSB0aW1lIGluIG9uZSBl bmNhcHN1bGF0b3IgZGV2aWNlLg0KPj4gDQo+PiBUaGUgZm9ybWVyIGlzIExJU1AgZW5jYXBz dWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBWWExBTiBlbmNhcHN1bGF0aW9uLg0KPj4gDQo+ PiBXaXRoIFZYTEFOLUdQRSBib3RoIGNhc2VzIGNhbiBiZSBzdXBwb3J0ZWQgKGFuZCBtb3N0 IGltcG9ydGFudGx5IHdpdGggYQ0KPj4gc2luZ2xlIHVuaWZpZWQgY29udHJvbC1wbGFuZSku DQo+PiANCj4+IFNvIEkgYmVsaWV2ZSBWWExBTi1HUEUgY291bGQgYmUgdXNlZnVsIHlldCBy ZWR1bmRhbnQgYnV0IExJU1AgcmVxdWlyZXMgbm8NCj4+IGNoYW5nZXMgKGlmIExJU1Agc3Vw cG9ydHMgIEwyIHdoaWNoIGlzIGRvY3VtZW50ZWQgaW4NCj4+IGRyYWZ0LXNtaXRoLWxpc3At bGF5ZXItMiB1c2luZyBhIGRpZmZlcmVudCBwb3J0IG51bWJlcikuDQo+PiANCj4+IERpbm8N Cj4+IA0KPj4+IE9uIEp1bCAyOSwgMjAxNCwgYXQgMzo1OCBBTSwgSGFvd2VpZ3VvIDxoYW93 ZWlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgRGlubywNCj4+PiBUaGFu a3MgZm9yIHlvdXIgZGV0YWlsIGNvbW1lbnRzLiAgQXMgZm9yIGN1cnJlbnQgVlhMQU4gZW5j YXBzdWxhdGlvbiwgcGxzDQo+Pj4gc2VlIG15IGNvbW1lbnRzIGlubGluZSB3aXRoIFt3ZWln dW9dIGJlbG93Lg0KPj4+IA0KPj4+IFRoZXJlIGlzIG1vdGl2YXRpb24gdG8gZXh0ZW5kIGFu IGVuY2Fwc3VsYXRpb24gaGVhZGVyICh3aGljaCBpcyBjYWxsZWQNCj4+PiBWWExBTi1HUEUp IHNvIGl0IGNhbiBzdXBwb3J0LCBtb3N0IGltcG9ydGFudGx5IE5TSC4gVGhhdCBjaGFuZ2Ug YWxzbyBnaXZlcw0KPj4+IFZYTEFOIHRvIHN1cHBvcnQgZW5jYXBzdWxhdGluZyBsYXllci0y IElQdjQgYW5kIElQdjYsIHdoaWNoIGlzIGR1cGxpY2F0ZQ0KPj4+IGZ1bmN0aW9uYWxpdHkg b2YgTElTUC4gQnV0IHRoZSBoZWFkZXJzIGFyZSBzbyBzaW1pbGFyLCBpdCByZWFsbHkgZG9l bnMndA0KPj4+IG1hdHRlci4NCj4+PiANCj4+PiBbd2VpZ3VvXTogWWVzLCBhbiBuZXcgZW5j YXBzdWxhdGlvbiBoZWFkZXIgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQNCj4+PiBO U0guIEJ1dCBhcyBmb3IgSVB2NCBhbmQgSVB2NiwgaSB0aGluayBjdXJyZW50IFZYTEFOIGFs cmVhZHkgc3VwcG9ydGVkLg0KPj4+IEZvciB0aGUgbGF5ZXIgMyBpbnRlci1zdWJuZXQgdHJh ZmZpYyBmcm9tIE5WRTEgdG8gTlZFMiwgaW5uZXIgZGVzdGluYXRpb24NCj4+PiBNQUMgaXMg dGhlIGdhdGV3YXkgaW50ZXJmYWNlIE1BQyBhdCBOVkUyLiAgRm9yIHRoZSBsYXllciAyIGlu dHJhLXN1Ym5ldA0KPj4+IHRyYWZmaWMgZnJvbSBOVkUxIHRvIE5WRTIsICBpbm5lciBkZXN0 aW5hdGlvbiBNQUMgaXMgdGhlIGRlc3RpbmF0aW9uIFRTJ3MNCj4+PiBNQUMuIFdoZW4gTlZF MiByZWNlaXZlcyBWWExBTiBlbmNhcHN1bGF0ZWQgdHJhZmZpYyBmcm9tIE5WRTEsIGlubmVy DQo+Pj4gZGVzdGluYXRpb24gTUFDIGNhbiBiZSB1c2VkIHRvIGRpZmZlcmVudGlhdGUgbGF5 ZXIgMiB0cmFmZmljIGZyb20gbGF5ZXIgMw0KPj4+IHRyYWZmaWMuIFZYTEFOIGRpc3RyaWJ1 dGVkIGxheWVyIDMgZ2F0ZXdheSBjYW4gYmUgcmVhbGl6ZWQgdGhyb3VnaCB0aGUNCj4+PiBt ZWNoYW5pc20sIE5WRSBjYW4gZm9yd2FyZCBib3RoIGludHJhLXN1Ym5ldCBsYXllciAyIHRy YWZmaWMgYW5kDQo+Pj4gaW50ZXItc3VibmV0IGxheWVyIDMgdHJhZmZpYyBhdCB0aGUgc2Ft ZSB0aW1lLg0KPj4+IA0KPj4+IFRoYW5rcw0KPj4+IHdlaWd1bw0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiC3orz+yMs6IERpbm8gRmFyaW5h Y2NpIFtmYXJpbmFjY2lAZ21haWwuY29tXQ0KPj4+ILeiy83KsbzkOiAyMDE0xOo31MIyOMjV IDIyOjE3DQo+Pj4gytW8/sjLOiBIYW93ZWlndW8NCj4+PiCzrcvNOiBEYXZpZCBNZWxtYW47 IG52bzNAaWV0Zi5vcmc7IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IFRvbSBIZXJiZXJ0DQo+ Pj4g1vfM4jogUmU6IFtudm8zXSBDb21tZW50cyBvbg0KPj4+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPj4+IA0KPj4+PiBIaSBEaW5v LA0KPj4+PiBTb3JyeSwgaSBtaXN1bmRlcnN0b29kIHlvdS4gSSB0aGluayBWWExBTi1HUEUg Y2FuIGRlZmluZSBhIG5ldyBVRFAgcG9ydA0KPj4+PiBhbmQgYSBuZXcgZGF0YSBmb3JtYXQs IFAgYml0DQo+Pj4gDQo+Pj4gTm8gd29ycmllcy4NCj4+PiANCj4+Pj4gaW4gVlhMQU4tR1BF IHNlZW1zIHRvIGhhdmUgbm8gYW55IHZhbHVlLiBBcyBmb3IgYmFzaWMgaW50ZXItc3VibmV0 IGxheWVyDQo+Pj4+IDMgY29tbXVuaWNhdGlvbiBhbmQgaW50cmEtc3VibmV0IGxheWVyIDIg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIE5WRXMsDQo+Pj4+IGN1cnJlbnQgTlZHUkUsIFZYTEFO IGFuZCBMSVNQIGhhdmUgYWxyZWFkeSBzdXBwb3J0ZWQsDQo+Pj4gDQo+Pj4gVlhMQU4gc3Vw cG9ydHMgTDIgb3ZlcmxheXMgc2luY2UgaXRzIGdvYWwgaXMgdG8gZXh0ZW5kIHN1Ym5ldHMu IExJU1ANCj4+PiBzdXBwb3J0cyBMMyBvdmVybGF5cyBzbyBpdCBhc3N1bWVzIHN1Ym5ldHMg YXJlIGxvY2FsICh0byB0aGUgeFRSKSBqdXN0DQo+Pj4gbGlrZSBpbiBhIHJvdXRlZCBuZXR3 b3JrLiBOVkdSRSBjYW4gYmUgYSBjb21iby4NCj4+PiANCj4+Pj4gTlZHUkUsVlhMQU4sTElT UCBhbmQgVlhMQU4tR1BFIGNhbiBiZSBoeWJyaWQgdXNlZCB0byBmb3JtIGEgTlZPMyBuZXR3 b3JrDQo+Pj4+IGlmIG9ubHkgYmFzaWMgbGF5ZXIgMyBhbmQNCj4+PiANCj4+PiBUaGVyZSBp cyBtb3RpdmF0aW9uIHRvIGV4dGVuZCBhbiBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2gg aXMgY2FsbGVkDQo+Pj4gVlhMQU4tR1BFKSBzbyBpdCBjYW4gc3VwcG9ydCwgbW9zdCBpbXBv cnRhbnRseSBOU0guIFRoYXQgY2hhbmdlIGFsc28gZ2l2ZXMNCj4+PiBWWExBTiB0byBzdXBw b3J0IGVuY2Fwc3VsYXRpbmcgbGF5ZXItMiBJUHY0IGFuZCBJUHY2LCB3aGljaCBpcyBkdXBs aWNhdGUNCj4+PiBmdW5jdGlvbmFsaXR5IG9mIExJU1AuIEJ1dCB0aGUgaGVhZGVycyBhcmUg c28gc2ltaWxhciwgaXQgcmVhbGx5IGRvZW5zJ3QNCj4+PiBtYXR0ZXIuDQo+Pj4gDQo+Pj4g SG93ZXZlciwgdGhlIFAtYml0IGlzIG5vdCBuZWVkZWQgZm9yIGFueXRoaW5nIG5ldyBpbiBM SVNQIGFuZCB0aGUgT0FNLWJpdA0KPj4+IGlzIG5vdCBuZWVkZWQgaW4gTElTUCBzaW5jZSBM SVNQIGhhcyBkaWZmZXJlbnQgVURQIHBvcnQgbnVtYmVyICg0MzQyKSBmb3INCj4+PiBjb250 cm9sLXBhY2tldHMuIFZYTEFOIGRvZXMgbm90IGhhdmUgYSB3ZWxsIGRlZmluZWQgY29udHJv bCBwcm90b2NvbCBzbw0KPj4+IHRoZSBkYXRhLXBsYW5lIGhhcyB0byBlc2NhcGUgb3V0IGNv bnRyb2wtcGxhbmUgcGFrY2V0cyB3aGVyZSB0aGUgZmlyc3Qgb25lDQo+Pj4gaXMgdGhpcyBu ZXcgT0FNIG1lc3NhZ2UuDQo+Pj4gDQo+Pj4+IGxheWVyIDIgZm9yd2FyZGluZyBwcm9jZXNz IGV4aXN0cy4gQXMgZm9yIHNvbWUgZXh0cmEgZnVuY3Rpb25zIG9mIE9BTSwNCj4+Pj4gc2Vy dmljZSBjaGFpbmluZyxhbmQgZXRjLCAgb25seSBWWExBTi1HUEUgY2FuIHN1cHBvcnQsIHB1 cmUgVlhMQU4tR1BFDQo+Pj4+IG5ldHdvcmsgc2hvdWxkIGJlIHVzZWQgaW4gdGhlc2UgY2Fz ZXMuDQo+Pj4+IFRoYW5rcw0KPj4+PiB3ZWlndW8NCj4+PiANCj4+PiBSaWdodCwgYWdyZWUu DQo+Pj4gDQo+Pj4gRGlubw0KPj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gt6K8/sjLOiBEaW5vIEZhcmlu YWNjaSBbZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4+Pj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjI4 yNUgMjE6MTUNCj4+Pj4gytW8/sjLOiBIYW93ZWlndW8NCj4+Pj4gs63LzTogVG9tIEhlcmJl cnQ7IERhdmlkIE1lbG1hbjsgbnZvM0BpZXRmLm9yZzsgTElTUCBtYWlsaW5nIGxpc3QgbGlz dA0KPj4+PiDW98ziOiBSZTogtPC4tDogW252bzNdIENvbW1lbnRzIG9uDQo+Pj4+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZS0wMw0KPj4+PiAN Cj4+Pj4+IE9uIEp1bCAyOCwgMjAxNCwgYXQgNzoyNCBBTSwgSGFvd2VpZ3VvIDxoYW93ZWln dW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEFib3V0IGJhY2t3YXJkIGNv bXBhdGliaWxpdHksIGkgYWxzbyBhZ3JlZSB3aXRoIERpbm8uIFZYTEFOLUdQRSBzaG91bGQN Cj4+Pj4+IGZvY3VzIG9uICB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVxdWlyZXMgdGhl IGFzc2lnbm1lbnQgb2YgYSBuZXcgVURQDQo+Pj4+PiBwb3J0LCB0aGUgZGF0YSBmb3JtYXQg ZG9uJ3QgbmVlZCBjb25zaWRlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgNCj4+Pj4+ IFZYTEFOIGhlYWRlci4gSQ0KPj4+PiANCj4+Pj4gSSB3YW50IHRvIG1ha2UgaXQgY2xlYXIg dGhhdCBzdXBwb3J0aW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgdmVyeQ0KPj4+PiBp bXBvcnRhbnQgc2luY2UgVlhMQU4tcG9ydC00Nzg5IGlzIHN1cHBvcnRlZCBpbiB2YXJpb3Vz IGNoaXBzIGFscmVhZHkuDQo+Pj4+IA0KPj4+PiBEaW5vDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbnZvMyBtYWlsaW5nIGxpc3QN Cj4+IG52bzNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnZvMw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw== From nobody Wed Jul 30 14:46:19 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87081A00A6 for ; Wed, 30 Jul 2014 14:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzaEHqscapBG for ; Wed, 30 Jul 2014 14:46:16 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EC81A0087 for ; Wed, 30 Jul 2014 14:46:16 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so8165081igb.14 for ; Wed, 30 Jul 2014 14:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OfUct+sRxOMQif9heMFz7ECwVA5kInTTht9URQGyoPI=; b=Zpli9aaHkhRB9RHvyYmhGNWd7bDdrFY01h78NP92aDAjYgy/n1UT2WC/bdDkUB8Ift soC/uWK7DAE5vHoK201LNAZ+/olNCCeldbF+Ut9oE/lO/7blkhzwPEhx6B174+XPYUj5 G4UkHISw8SpV5xsJ0jTGxy+z3NR0jUPsDfHMmRWUMN88CgtzgHF70pckNX+w+l2Rd1Gw vTJqfI4QOeMhUuwFe006zHPw00k4fYLemIyhkBLaU5ttDpMLEA+bdSthkDPneq3YTnll uMXCHGqTFGp1ixHbdYkJRjSD72r7yUlunWX/lV1VmIZuz64edTDEBz60euG2lMHbrStv rOwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OfUct+sRxOMQif9heMFz7ECwVA5kInTTht9URQGyoPI=; b=ezajzp+K4pegO+oggih/h3r9GQRrT7tbxvl1sihHNybpR4jiN+3waDOHNGdjAyKdYf DkQe7J/195jxRL/niMBfAqfkGlh7yeFFWjlIMywbSP6+c7fJEgWcD5B+NTJGve+eSjdj Ye3yKEJ2tujZyM+aa9JPNxRexjEFflj8imX+6qj5ayPSoAxMbdTNF5KTlp/w1GggoEdm SfZ/I7kniqQ6alRMubSPc6Vjo/6n29mkG+QXRNcDbbPOyKaIINQFN/sdPCzDMhaD0pSR xwtYKi12LhwgItMKp+UtK5MTW7ZgubCR26GYPNJzohAe1YgY1YJ5kUgllR02wz5F1X7r cAKA== X-Gm-Message-State: ALoCoQkevF2R8mXdj95nijji4tgVeclfeJUJfmeNVxh4WgXDV2hk4QTlmGmbCU/ogwQywAA9AmPf MIME-Version: 1.0 X-Received: by 10.42.252.201 with SMTP id mx9mr9447097icb.78.1406756775563; Wed, 30 Jul 2014 14:46:15 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Wed, 30 Jul 2014 14:46:15 -0700 (PDT) In-Reply-To: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com>