From nobody Tue Dec 1 15:06:16 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1CA1B29EB; Tue, 1 Dec 2015 15:06:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201230607.18661.33492.idtracker@ietfa.amsl.com> Date: Tue, 01 Dec 2015 15:06:07 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, draft-ietf-lisp-impact@ietf.org, rfc-editor@rfc-editor.org, The IESG Subject: [lisp] Document Action: 'LISP Impact' to Informational RFC (draft-ietf-lisp-impact-05.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: Tue, 01 Dec 2015 23:06:07 -0000 The IESG has approved the following document: - 'LISP Impact' (draft-ietf-lisp-impact-05.txt) as Informational RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ Technical Summary The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. LISP comprises both a tunnel-based data plane and a distributed control plane for the Internet, and requires some new functionalities, such as RLOC reachability mechanisms. The main goal of LISP is to make the Internet more scalable by reducing the number of prefixes announced in the Default Free Zone (DFZ). However, as LISP relies on mapping and encapsulation, it turns out that it provides more benefits than just increased scalability. LISP architecture facilitates routing in environments where there is little to no correlation between network endpoints and topological location. In service provider environment this use is evident in a range of consumer use cases which require an inline anchor in-order to deliver a service to a subscribers. Inline anchors provide one of three types of capabilities: o enable mobility of subscriber end points o enable chaining of middle-box functions and services o enable seamless scale-out of functions Working Group Summary There was no major controversy. The WG had a debate on the impact of cache size, i.e., cache performance, control overhead and scalability of control plane (related to results published in one particular research paper [CCD12]), which triggered two revisions of the document. Document Quality Are there existing implementations of the protocol? Yes, there are multiple implementations of LISP (at least 3) Have a significant number of vendors indicated their plan to implement the specification? At least one major vendor (Cisco) has already implemented LISP specification. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Review by Ross Callon triggered two revisions of the document but without major changes. Reviewer was satisfied with version 03 of the document If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document does not require a MIB doctor Personnel Wassim Haddad is the document shepherd. The responsible area director is Deborah Brungard. From nobody Fri Dec 4 10:55:26 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A591B321F; Fri, 4 Dec 2015 10:55:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151204185525.9579.29234.idtracker@ietfa.amsl.com> Date: Fri, 04 Dec 2015 10:55:25 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-03.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 Dec 2015 18:55:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Data-Plane Confidentiality Authors : Dino Farinacci Brian Weis Filename : draft-ietf-lisp-crypto-03.txt Pages : 17 Date : 2015-12-04 Abstract: This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-crypto-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-crypto-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 4 10:58:03 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9051E1B3256 for ; Fri, 4 Dec 2015 10:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 lt402EHnQBOR for ; Fri, 4 Dec 2015 10:57:53 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FEF1B3252 for ; Fri, 4 Dec 2015 10:57:53 -0800 (PST) Received: by pacdm15 with SMTP id dm15so90725148pac.3 for ; Fri, 04 Dec 2015 10:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=W7nHngMOY1VO6mJ97JD19m2kUobSoY6B4sfJb2Uc6JM=; b=cf4CJpQPyNnmnu9LKfpBVD0Q5n7ej/H75kEpbsEPO1sxg3CmXEDnuT1qe33FN1V+Tp FM1CahPPt6EynKrvhtaJtDWw2WA/ZvM/K5zlWGebh0pygkInZ9e6vgJaX7lkSF9NBS6I FPMl0QN4T1wRBGevg3a76xBCVVThjK1T3aY+nc4nxvjJxG7jcw7umRJ5dvVpFp/jYudj oDwV32dLfat2S5FYvKpiLkX6TBSDg/inbthnVJFV+Cxt02o3wLviCP8u/EvXWjex5SwW bmk9Onidc2v/MpXY2bR+P7Qlz4vGtWHy09ivrieju9WekGyJ6At/YTpZqq7I35TCRwzq 9Weg== X-Received: by 10.66.192.42 with SMTP id hd10mr23415293pac.111.1449255472761; Fri, 04 Dec 2015 10:57:52 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id c1sm18675390pas.1.2015.12.04.10.57.49 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 10:57:51 -0800 (PST) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_93271C04-11AF-4AFB-BD49-27B450724A2A" Message-Id: <1DE57D39-BCC6-4FF5-80D4-E0B6301D319F@gmail.com> Date: Fri, 4 Dec 2015 10:57:53 -0800 To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [lisp] New draft-ietf-lisp-crypto-03 update 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 Dec 2015 18:58:00 -0000 --Apple-Mail=_93271C04-11AF-4AFB-BD49-27B450724A2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, Ilari, and I have put in some substantial time for this draft. = Changes include: B.1. Changes to draft-ietf-lisp-crypto-03.txt o Posted December 2015. o Changed cipher suite allocations. We now have 2 AES-CBC cipher suites for compatibility, 3 AES-GCM cipher suites that are faster ciphers that include AE and a Chacha20-Poly1305 cipher suite which is the fastest but not totally proven/accepted.. o Remove 1024-bit DH keys for key exchange. o Make clear that AES and chacha20 ciphers use AEAD so part of encrytion/decryption does authentication. o Make it more clear that separate key pairs are used in each direction between xTRs. o Indicate that the IV length is different per cipher suite. o Use a counter based IV for every packet for AEAD ciphers. Previously text said to use a random number. But CBC ciphers, use a random number. o Indicate that key material is sent in network byte order (big endian). o Remove A-bit from Security Type LCAF. No need to do authentication only with the introduction of AEAD ciphers. These ciphers can do authentication. So you get ciphertext for free. o Remove language that refers to "encryption-key" and "integrity- key". Used term "AEAD-key" that is used by the AEAD cipher suites that do encryption and authenticaiton internal to the cipher. Thanks, Dino/Brian --Apple-Mail=_93271C04-11AF-4AFB-BD49-27B450724A2A Content-Disposition: attachment; filename=rfcdiff.html Content-Type: text/html; name="rfcdiff.html" Content-Transfer-Encoding: 7bit Content-Type: text/html Diff: draft-ietf-lisp-crypto-02.txt - draft-ietf-lisp-crypto-03.txt
< draft-ietf-lisp-crypto-02.txt   draft-ietf-lisp-crypto-03.txt >
Internet Engineering Task Force D. Farinacci Internet Engineering Task Force D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental B. Weis Intended status: Experimental B. Weis
Expires: March 11, 2016 cisco Systems Expires: June 6, 2016 cisco Systems
September 8, 2015 December 4, 2015
LISP Data-Plane Confidentiality LISP Data-Plane Confidentiality
draft-ietf-lisp-crypto-02 draft-ietf-lisp-crypto-03
Abstract Abstract
This document describes a mechanism for encrypting LISP encapsulated This document describes a mechanism for encrypting LISP encapsulated
traffic. The design describes how key exchange is achieved using traffic. The design describes how key exchange is achieved using
existing LISP control-plane mechanisms as well as how to secure the existing LISP control-plane mechanisms as well as how to secure the
LISP data-plane from third-party surveillance attacks. LISP data-plane from third-party surveillance attacks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2016. This Internet-Draft will expire on June 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3 3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3
4. Encoding and Transmitting Key Material . . . . . . . . . . . 4 4. Encoding and Transmitting Key Material . . . . . . . . . . . 4
5. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7 5. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7
6. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 8 6. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 9
7. Procedures for Encryption and Decryption . . . . . . . . . . 10 7. Procedures for Encryption and Decryption . . . . . . . . . . 10
8. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 8. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11
9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 10.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12
10.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12 10.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 15 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 15
B.1. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 15 B.1. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 15
B.2. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 15 B.2. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 16
B.3. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 15 B.3. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 16
B.4. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 15 B.4. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 16
B.5. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 16 B.5. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 B.6. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [RFC6830] defines a set of The Locator/ID Separation Protocol [RFC6830] defines a set of
functions for routers to exchange information used to map from non- functions for routers to exchange information used to map from non-
routable Endpoint Identifiers (EIDs) to routable Routing Locators routable Endpoint Identifiers (EIDs) to routable Routing Locators
(RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs.
Packets that arrive at the ITR or PITR are typically not modified. Packets that arrive at the ITR or PITR are typically not modified.
Which means no protection or privacy of the data is added. If the Which means no protection or privacy of the data is added. If the
source host encrypts the data stream then the encapsulated packets source host encrypts the data stream then the encapsulated packets
skipping to change at page 3, line 37 skipping to change at page 3, line 40
ITR needs to obtain the RLOC of an ETR, it will get security material ITR needs to obtain the RLOC of an ETR, it will get security material
to compute a shared secret with the ETR. to compute a shared secret with the ETR.
The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating
to. And when the ITR encrypts a packet before encapsulation, it will to. And when the ITR encrypts a packet before encapsulation, it will
identify the key it used for the crypto calculation so the ETR knows identify the key it used for the crypto calculation so the ETR knows
which key to use for decrypting the packet after decapsulation. By which key to use for decrypting the packet after decapsulation. By
using key-ids in the LISP header, we can also get real-time rekeying using key-ids in the LISP header, we can also get real-time rekeying
functionality. functionality.
When an ETR (when it is also an ITR) encapsulates packets to this ITR
(when it is also an ETR), a separate key exchange and shared-secret
computation is performed. The key management described in this
documemnt is unidirectional from the ITR (the encapsulator) to the
ETR (the decapsultor).
3. Diffie-Hellman Key Exchange 3. Diffie-Hellman Key Exchange
LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and
computation for computing a shared secret. The Diffie-Hellman computation for computing a shared secret. The Diffie-Hellman
parameters will be passed via Cipher Suite code-points in Map-Request parameters will be passed via Cipher Suite code-points in Map-Request
and Map-Reply messages. and Map-Reply messages.
Here is a brief description how Diff-Hellman works: Here is a brief description how Diff-Hellman works:
+----------------------------+---------+----------------------------+ +----------------------------+---------+----------------------------+
skipping to change at page 5, line 12 skipping to change at page 5, line 12
Map-Reply messages. Diffie-Hellman parameters are encoded in the Map-Reply messages. Diffie-Hellman parameters are encoded in the
LISP Security Type LCAF [LCAF]. LISP Security Type LCAF [LCAF].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Rsvd2 | 6 + n | | Type = 11 | Rsvd2 | 6 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Count | Rsvd3 |A| Cipher Suite| Rsvd4 |R| | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Length | Public Key Material ... | | Key Length | Public Key Material ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Public Key Material | | ... Public Key Material |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Locator Address ... | | AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions
The 'Key Count' field encodes the number of {'Key-Length', 'Key- The 'Key Count' field encodes the number of {'Key-Length', 'Key-
Material'} fields included in the encoded LCAF. The maximum number Material'} fields included in the encoded LCAF. The maximum number
of keys that can be encoded are 3, each identified by key-id 1, of keys that can be encoded are 3, each identified by key-id 1,
followed by key-id 2, an finally key-id 3. followed by key-id 2, an finally key-id 3.
The 'R' bit is not used for this use-case of the Security Type LCAF The 'R' bit is not used for this use-case of the Security Type LCAF
but is reserved for [LISP-DDT] security. but is reserved for [LISP-DDT] security.
When the A-bit is set, it indicates that Authentication only is Cipher Suite 0:
performed according to the Integrity hash function defined in the Reserved
Cipher Suites. That is an encapsulator will perform an Integrity
computation over an unencrypted packet and include an ICV value.
Since the packet contains no ciphertext, there is no IV value
included in the message. The 7-bit 'Cipher Suite' field defines the
following code-points:
Cipher Suite 0: Cipher Suite 1:
Reserved Diffie-Hellman Group: 2048-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: Integrated with [AES-CBC] AEAD [RFC5116] encryption
IV length: 16 bytes
Cipher Suite 1: Cipher Suite 2:
Diffie-Hellman Group: 1024-bit Modular Exponential (MODP) [RFC2409] Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: HMAC-SHA1-96 [RFC2404] Integrity: HMAC-SHA1-96 [RFC2404]
IV length: 16 bytes
Cipher Suite 2: Cipher Suite 3:
Diffie-Hellman Group: 2048-bit MODP [RFC3526] Diffie-Hellman Group: 2048-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in GCM mode [AES-GCM]
Integrity: HMAC-SHA1-96 [RFC2404] Integrity: Integrated with [AES-GCM] AEAD [RFC5116] encryption
IV length: 12 bytes
Cipher Suite 3: Cipher Suite 4:
Diffie-Hellman Group: 3072-bit MODP [RFC3526] Diffie-Hellman Group: 3072-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in GCM mode [AES-GCM]
Integrity: HMAC-SHA1-96 [RFC2404] Integrity: Integrated with [AES-GCM] AEAD [RFC5116] encryption
IV length: 12 bytes
Cipher Suite 4: Cipher Suite 5:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in GCM mode [AES-GCM]
Integrity: HMAC-SHA1-96 [RFC2404] Integrity: Integrated with [AES-GCM] AEAD [RFC5116] encryption
IV length: 12 bytes
Cipher Suite 5: Cipher Suite 6:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: Chacha20-Poly1305 [CHACHA-POLY] Encryption/Integrity: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539]
Integrity: HMAC-SHA1-96 [RFC2404] Integrity: Integrated with Chacha20-Poly1305 AEAD [RFC1116] encryption
IV length: 8 bytes
The "Public Key Material" field contains the public key generated by The "Public Key Material" field contains the public key generated by
one of the Cipher Suites defined above. The length of the key in one of the Cipher Suites defined above. The length of the key in
octets is encoded in the "Key Length" field. octets is encoded in the "Key Length" field.
When an ITR or PITR send a Map-Request, they will encode their own When an ITR or PITR send a Map-Request, they will encode their own
RLOC in the Security Type LCAF format within the ITR-RLOCs field. RLOC in the Security Type LCAF format within the ITR-RLOCs field.
When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in
Security Type LCAF format within the RLOC-record field of each EID- Security Type LCAF format within the RLOC-record field of each EID-
record supplied. record supplied.
skipping to change at page 7, line 16 skipping to change at page 7, line 28
5. Shared Keys used for the Data-Plane 5. Shared Keys used for the Data-Plane
When an ITR or PITR receives a Map-Reply accepting the Cipher Suite When an ITR or PITR receives a Map-Reply accepting the Cipher Suite
sent in the Map-Request, it is ready to create data plane keys. The sent in the Map-Request, it is ready to create data plane keys. The
same process is followed by the ETR or RTR returning the Map-Reply. same process is followed by the ETR or RTR returning the Map-Reply.
The first step is to create a shared secret, using the peer's shared The first step is to create a shared secret, using the peer's shared
Diffie-Hellman Public Key Material combined with device's own private Diffie-Hellman Public Key Material combined with device's own private
keying material as described in Section 3. The Diffie-Hellman group keying material as described in Section 3. The Diffie-Hellman group
used is defined in the Cipher Suite sent in the Map-Request and used is defined in the cipher suite sent in the Map-Request and
copied into the Map-Reply. copied into the Map-Reply.
The resulting shared secret is used to compute Encryption and The resulting shared secret is used to compute an AEAD-key for the
Integrity keys for the algorithms specified in the Cipher Suite. A algorithms specified in the cipher suite. A Key Derivation Function
Key Derivation Function (KDF) in counter mode as specified by (KDF) in counter mode as specified by [NIST-SP800-108] is used to
[NIST-SP800-108] is used to generate the data-plane keys. The amount generate the data-plane keys. The amount of keying material that is
of keying material that is derived depends on the algorithms in the derived depends on the algorithms in the cipher suite.
cipher suite.
The inputs to the KDF are as follows: The inputs to the KDF are as follows:
o KDF function. This is HMAC-SHA-256. o KDF function. This is HMAC-SHA-256.
o A key for the KDF function. This is the most significant 16 o A key for the KDF function. This is the computed Diffie-Hellman
octets of the computed Diffie-Hellman shared secret. shared secret.
o Context that binds the use of the data-plane keys to this session. o Context that binds the use of the data-plane keys to this session.
The context is made up of the following fields, which are The context is made up of the following fields, which are
concatenated and provided as the data to be acted upon by the KDF concatenated and provided as the data to be acted upon by the KDF
function. function.
Context: Context:
o A counter, represented as a two-octet value in network-byte order. o A counter, represented as a two-octet value in network-byte order.
o The null-terminated string "lisp-crypto". o The null-terminated string "lisp-crypto".
o The ITR's nonce from the the Map-Request the Cipher Suite was o The ITR's nonce from the the Map-Request the cipher suite was
included in. included in.
o The number of bits of keying material required (L), represented as o The number of bits of keying material required (L), represented as
a two-octet value in network byte order. a two-octet value in network byte order.
The counter value in the context is first set to 1. When the amount The counter value in the context is first set to 1. When the amount
of keying material exceeds the number of bits returned by the KDF of keying material exceeds the number of bits returned by the KDF
function, then the KDF function is called again with the same inputs function, then the KDF function is called again with the same inputs
except that the counter increments for each call. When enough keying except that the counter increments for each call. When enough keying
material is returned, it is concatenated and used to create keys. material is returned, it is concatenated and used to create keys.
skipping to change at page 8, line 39 skipping to change at page 8, line 50
key-material-2 = HMAC-SHA-256(dh-shared-secret, context) key-material-2 = HMAC-SHA-256(dh-shared-secret, context)
where: context = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200 where: context = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200
key-material = key-material-1 || key-material-2 key-material = key-material-1 || key-material-2
If the key-material is longer than the required number of bits (L), If the key-material is longer than the required number of bits (L),
then only the most significant L bits are used. then only the most significant L bits are used.
From the derived key-material, the most significant bits are used for From the derived key-material, the most significant 256 bits are used
the Encryption key, and least significant bits are used for the for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided
Integrity key. For example, if the Cipher Suite contains both AES into a 128-bit encryption key and a 128-bit integrity-check key
with 128-bit keys and HMAC-SHA1-96, the most significant 128 bits internal to the cipher used by the ITR.
become the ITR's data-plane encryption key, and the next 128-bit
become the ITR's Integrity key.
6. Data-Plane Operation 6. Data-Plane Operation
The LISP encapsulation header [RFC6830] requires changes to encode The LISP encapsulation header [RFC6830] requires changes to encode
the key-id for the key being used for encryption. the key-id for the key being used for encryption.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L / |N|L|E|V|I|P|K|K| Nonce/Map-Version | \ L / |N|L|E|V|I|P|K|K| Nonce/Map-Version | \ \
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD
S \ | Instance ID/Locator-Status-Bits | | S \ | Instance ID/Locator-Status-Bits | | /
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initialization Vector (IV) | I | Initialization Vector (IV) | I
E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C
n / | | V n / | | V
c | | | c | | |
r | Packet Payload with EID Header ... | | r | Packet Payload with EID Header ... | |
y | | | y | | |
p \ | | / p \ | | /
t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K-bits indicate when packet is encrypted and which key used K-bits indicate when packet is encrypted and which key used
When the KK bits are 00, the encapsulated packet is not encrypted. When the KK bits are 00, the encapsulated packet is not encrypted.
When the value of the KK bits are 1, 2, or 3, it encodes the key-id When the value of the KK bits are 1, 2, or 3, it encodes the key-id
of the secret keys computed during the Diffie-Hellman Map-Request/ of the secret keys computed during the Diffie-Hellman Map-Request/
Map-Reply exchange. When the KK bits are not 0, the payload is Map-Reply exchange. When the KK bits are not 0, the payload is
prepended with an Initialization Vector (IV) and appended with an prepended with an Initialization Vector (IV). The length of the IV
Integrity Check Value (ICV). The length of the IV and ICV fields field is based on the cipher suite used. Since all cipher suites
depend on the Cipher Suite negotiated in the control-plane. defined in this document do Authenticated Encryption (AEAD), an ICV
field does not need to be present in the packet since it is included
in the ciphertext. The Additional Data (AD) used for the ICV is
shown above and includes the LISP header, the IV field and the packet
payload.
When an ITR or PITR receives a packet to be encapsulated, they will When an ITR or PITR receives a packet to be encapsulated, they will
first decide what key to use, encode the key-id into the LISP header, first decide what key to use, encode the key-id into the LISP header,
and use that key to encrypt all packet data that follows the LISP and use that key to encrypt all packet data that follows the LISP
header. Therefore, the outer header, UDP header, and LISP header header. Therefore, the outer header, UDP header, and LISP header
travel as plaintext. travel as plaintext.
There is an open working group item to discuss if the data There is an open working group item to discuss if the data
encapsulation header needs change for encryption or any new encapsulation header needs change for encryption or any new
applications. This draft proposes changes to the existing header so applications. This draft proposes changes to the existing header so
experimentation can continue without making large changes to the experimentation can continue without making large changes to the
data-plane at this time. data-plane at this time.
7. Procedures for Encryption and Decryption 7. Procedures for Encryption and Decryption
When an ITR, PITR, or RTR encapsulate a packet and have already When an ITR, PITR, or RTR encapsulate a packet and have already
computed an encryption-key and integrity-key (detailed in section computed an AEAD-key (detailed in section Section 5) that is
Section 5) that is associated with a destination RLOC, the following associated with a destination RLOC, the following encryption and
encryption and encapsulation procedures are performed: encapsulation procedures are performed:
1. The encapsulator creates a random number used as the IV. 1. The encapsulator creates an IV and prepends the IV value to the
Prepends the IV value to the packet being encapsulated. The IV packet being encapsulated. For GCM and Chacha cipher suites, the
is incremented for every packet sent to the destination RLOC. IV is incremented for every packet (beginning with a value of 1
in the first packet) and sent to the destination RLOC. For CBC
cipher suites, the IV is a new random number for every packet
sent to the destination RLOC. For the Chacha cipher suite, the
IV is an 8-byte random value that is appended to a 4-byte counter
that is incremented for every packet (beginning with a value of 1
in the first packet).
2. Next encrypt with cipher function AES-CBC using the encryption- 2. Next encrypt with cipher function AES or Chacha20 using the AEAD-
key over the packet payload. This does not include the IV. The key over the packet payload following the AEAD specification
IV must be transmitted as plaintext so the decrypter can use it referenced in the cipher suite definition. This does not include
as input to the decryption cipher. The payload should be padded the IV. The IV must be transmitted as plaintext so the decrypter
to an integral number of bytes a block cipher may require. can use it as input to the decryption cipher. The payload should
be padded to an integral number of bytes a block cipher may
require. The result of the AEAD operation may contain an ICV,
the size of which is defined by the referenced AEAD
specification. Note that the AD (i.e. the LISP header exactly as
will be prepended in the next step and the IV) must be given to
the AEAD encryption function as the "associated data" argument.
3. Prepend the LISP header. The key-id field of the LISP header is 3. Prepend the LISP header. The key-id field of the LISP header is
set to the key-id value that corresponds to key-pair used for the set to the key-id value that corresponds to key-pair used for the
encryption cipher and for the ICV hash. encryption cipher.
4. Next compute the ICV value by hashing the packet (which includes
the LISP header, the IV, and the packet payload) with the HMAC-
SHA1 function using the integrity-key. The resulting ICV value
is appended to the packet. The ICV is not ciphertext so a fast
integrity check can be performed without decryption at the
receiver.
5. Lastly, prepend the UDP header and outer IP header onto the 4. Lastly, prepend the UDP header and outer IP header onto the
encrypted packet and send packet to destination RLOC. encrypted packet and send packet to destination RLOC.
When an ETR, PETR, or RTR receive an encapsulated packet, the When an ETR, PETR, or RTR receive an encapsulated packet, the
following decapsulation and decryption procedures are performed: following decapsulation and decryption procedures are performed:
1. The outer IP header and UDP header are stripped from the start of 1. The outer IP header, UDP header, LISP header, and IV field are
the packet and the ICV is stripped from the end of the packet. stripped from the start of the packet. The LISP header and IV
are retained and given to the AEAD decryption operation as the
2. Next the ICV is computed by running the Integrity function from "associated data" argument.
the cipher suite using the integrity-key over the packet (which
includes the LISP header, the IV and packet payload) using the
integrity-key. If the result does not match the ICV value from
the packet, the packet was been tampered with, and is dropped,
and an optional log message may be issued. The integrity-key is
obtained from a local-cache associated with the key-id value from
the LISP header.
3. If the hashed result matches the ICV value from the packet, then
the LISP header is stripped and decryption occurs over the packet
payload using the plaintext IV in the packet.
4. The IV is stripped from the packet.
5. The packet is decrypted using the encryption-key and the IV from 2. The packet is decrypted using the AEAD-key and the IV from the
the packet. The encryption-key is obtained from a local-cache packet. The AEAD-key is obtained from a local-cache associated
associated with the key-id value from the LISP header. The with the key-id value from the LISP header. The result of the
result of the decryption function is a plaintext packet payload. decryption function is a plaintext packet payload if the cipher
returned a verified ICV. Otherwise, the packet has been tampered
with, is dropped, and an optional log message may be issued. If
the AEAD specification included an ICV, the AEAD decryption
function will locate the ICV in the ciphertext and compare it to
a version of the ICV that the AEAD decryption function computes.
If the computed ICV is different than the ICV located in the
ciphertext, then it will be considered tampered.
6. The resulting packet is forwarded to the destination EID. 3. If the packet was not tampered with, the decrypted packet is
forwarded to the destination EID.
8. Dynamic Rekeying 8. Dynamic Rekeying
Since multiple keys can be encoded in both control and data messages, Since multiple keys can be encoded in both control and data messages,
an ITR can encapsulate and encrypt with a specific key while it is an ITR can encapsulate and encrypt with a specific key while it is
negotiating other keys with the same ETR. Soon as an ETR or RTR negotiating other keys with the same ETR. Soon as an ETR or RTR
returns a Map-Reply, it should be prepared to decapsulate and decrypt returns a Map-Reply, it should be prepared to decapsulate and decrypt
using the new keys computed with the new Diffie-Hellman parameters using the new keys computed with the new Diffie-Hellman parameters
received in the Map-Request and returned in the Map-Reply. received in the Map-Request and returned in the Map-Reply.
skipping to change at page 12, line 18 skipping to change at page 12, line 23
9. Future Work 9. Future Work
For performance considerations, newer Elliptic-Curve Diffie-Hellman For performance considerations, newer Elliptic-Curve Diffie-Hellman
(ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to
reduce CPU cycles required to compute shared secret keys. reduce CPU cycles required to compute shared secret keys.
For better security considerations as well as to be able to build For better security considerations as well as to be able to build
faster software implementations, newer approaches to ciphers and faster software implementations, newer approaches to ciphers and
authentication methods will be researched and tested. Some examples authentication methods will be researched and tested. Some examples
are chacha20 and poly1305 [CHACHA-POLY]. are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539].
10. Security Considerations 10. Security Considerations
10.1. SAAG Support 10.1. SAAG Support
The LISP working group has and will continue to seek help from the The LISP working group has and will continue to seek help from the
SAAG working group for security advice. The SAAG has been involved SAAG working group for security advice. The SAAG has been involved
early in the design process so they have early input and review. early in the design process so they have early input and review.
10.2. LISP-Crypto Security Threats 10.2. LISP-Crypto Security Threats
skipping to change at page 14, line 15 skipping to change at page 14, line 19
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>. <http://www.rfc-editor.org/info/rfc6090>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<http://www.rfc-editor.org/info/rfc7539>.
12.2. Informative References 12.2. Informative References
[AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead-
aes-cbc-hmac-sha2-05.txt (work in progress). aes-cbc-hmac-sha2-05.txt (work in progress).
[CHACHA-POLY] [CHACHA-POLY]
Langley, A., "ChaCha20 and Poly1305 based Cipher Suites Langley, A., "ChaCha20 and Poly1305 based Cipher Suites
for TLS", draft-agl-tls-chacha20poly1305-00 (work in for TLS", draft-agl-tls-chacha20poly1305-00 (work in
progress). progress).
skipping to change at page 15, line 7 skipping to change at page 15, line 17
"LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-06 (work "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-06 (work
in progress). in progress).
[NIST-SP800-108] [NIST-SP800-108]
"National Institute of Standards and Technology, "National Institute of Standards and Technology,
"Recommendation for Key Derivation Using Pseudorandom "Recommendation for Key Derivation Using Pseudorandom
Functions NIST SP800-108"", NIST SP 800-108, October 2009. Functions NIST SP800-108"", NIST SP 800-108, October 2009.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The author would like to thank Dan Harkins, Joel Halpern, Fabio The authors would like to thank Dan Harkins, Joel Halpern, Fabio
Maino, Ed Lopez, Roger Jorgensen, Watson Ladd, and Ilari Liusvaara Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest,
for their interest, suggestions, and discussions about LISP data- suggestions, and discussions about LISP data-plane security.
plane security.
The authors would like to give a special thank you to Ilari Liusvaara
for his extensive commentary and discussion. He has contributed his
security expertise to make lisp-crypto as secure as the state of the
art in cryptography.
In addition, the support and suggestions from the SAAG working group In addition, the support and suggestions from the SAAG working group
were helpful and appreciative. were helpful and appreciative.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-crypto-01.txt B.1. Changes to draft-ietf-lisp-crypto-03.txt
o Posted December 2015.
o Changed cipher suite allocations. We now have 2 AES-CBC cipher
suites for compatibility, 3 AES-GCM cipher suites that are faster
ciphers that include AE and a Chacha20-Poly1305 cipher suite which
is the fastest but not totally proven/accepted..
o Remove 1024-bit DH keys for key exchange.
o Make clear that AES and chacha20 ciphers use AEAD so part of
encrytion/decryption does authentication.
o Make it more clear that separate key pairs are used in each
direction between xTRs.
o Indicate that the IV length is different per cipher suite.
o Use a counter based IV for every packet for AEAD ciphers.
Previously text said to use a random number. But CBC ciphers, use
a random number.
o Indicate that key material is sent in network byte order (big
endian).
o Remove A-bit from Security Type LCAF. No need to do
authentication only with the introduction of AEAD ciphers. These
ciphers can do authentication. So you get ciphertext for free.
o Remove language that refers to "encryption-key" and "integrity-
key". Used term "AEAD-key" that is used by the AEAD cipher suites
that do encryption and authenticaiton internal to the cipher.
B.2. Changes to draft-ietf-lisp-crypto-02.txt
o Posted September 2015. o Posted September 2015.
o Add cipher suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Elliptic Curve 25519 DH exchange.
o Add cipher suite for Chacha20/poly1305 ciphers. o Add cipher suite for Chacha20/Poly1305 ciphers.
B.2. Changes to draft-ietf-lisp-crypto-01.txt B.3. Changes to draft-ietf-lisp-crypto-01.txt
o Posted May 2015. o Posted May 2015.
o Create cipher suites and encode them in the Security LCAF. o Create cipher suites and encode them in the Security LCAF.
o Add IV to beginning of packet header and ICV to end of packet. o Add IV to beginning of packet header and ICV to end of packet.
o AEAD procedures are now part of encrpytion process. o AEAD procedures are now part of encrpytion process.
B.3. Changes to draft-ietf-lisp-crypto-00.txt B.4. Changes to draft-ietf-lisp-crypto-00.txt
o Posted January 2015. o Posted January 2015.
o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto-
00. This draft has become a working group document 00. This draft has become a working group document
o Add text to indicate the working group may work on a new data o Add text to indicate the working group may work on a new data
encapsulation header format for data-plane encryption. encapsulation header format for data-plane encryption.
B.4. Changes to draft-farinacci-lisp-crypto-01.txt B.5. Changes to draft-farinacci-lisp-crypto-01.txt
o Posted July 2014. o Posted July 2014.
o Add Group-ID to the encoding format of Key Material in a Security o Add Group-ID to the encoding format of Key Material in a Security
Type LCAF and modify the IANA Considerations so this draft can use Type LCAF and modify the IANA Considerations so this draft can use
key exchange parameters from the IANA registry. key exchange parameters from the IANA registry.
o Indicate that the R-bit in the Security Type LCAF is not used by o Indicate that the R-bit in the Security Type LCAF is not used by
lisp-crypto. lisp-crypto.
skipping to change at page 16, line 23 skipping to change at page 17, line 23
process. process.
o Add text indicating that when RLOC-probing is used for RLOC o Add text indicating that when RLOC-probing is used for RLOC
reachability purposes and rekeying is not desired, that the same reachability purposes and rekeying is not desired, that the same
key exchange parameters should be used so a reallocation of a key exchange parameters should be used so a reallocation of a
pubic key does not happen at the ETR. pubic key does not happen at the ETR.
o Add text to indicate that ECDH can be used to reduce CPU o Add text to indicate that ECDH can be used to reduce CPU
requirements for computing shared secret-keys. requirements for computing shared secret-keys.
B.5. Changes to draft-farinacci-lisp-crypto-00.txt B.6. Changes to draft-farinacci-lisp-crypto-00.txt
o Initial draft posted February 2014. o Initial draft posted February 2014.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, California 95120 San Jose, California 95120
USA USA
 End of changes. 39 change blocks. 
118 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail=_93271C04-11AF-4AFB-BD49-27B450724A2A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_93271C04-11AF-4AFB-BD49-27B450724A2A-- From nobody Fri Dec 4 17:01:21 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ADC1B34BB for ; Fri, 4 Dec 2015 17:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1LdBOPbJQ4C for ; Fri, 4 Dec 2015 17:01:17 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FD51B34BA for ; Fri, 4 Dec 2015 17:01:17 -0800 (PST) Received: by pabfh17 with SMTP id fh17so97160025pab.0 for ; Fri, 04 Dec 2015 17:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=skiA66HCNkH9NJDg3htREyiuIGgT+fI/zEGopJsGs4I=; b=GhniAf5LL3gyiMB8RRGhQ79M5kjHX3d9QQ9wuCBaEI4p8NZft7S6p68aGCLWVel7I/ 01JpQhuXn5x8wNkEuaHnaz0CVx2WAs5QRh3SIU0p5rDSM6BlcrIIA0eK73rIcbgby481 zovu4aNurLBxxR99KhPrpE8bWp3/nDCgbPuhZz8xZ5QZmOI1K7kQVdu1r7C7CIhhVAaE KXNgmkObhNEo9f7te3ZHrj9yEv3MG4MxNE+eRQ2ZWQ6R5kzsbJYPF46mUEQcR0Jg+B8x i71czzzniOTOcExX9NEytxDwA4UlXUnhUiUx4zrWFSE/IM2kIhf3Us9sQ2/sI0916NvI rnxw== X-Received: by 10.66.120.47 with SMTP id kz15mr25436868pab.84.1449277277383; Fri, 04 Dec 2015 17:01:17 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id h9sm19447945pfj.69.2015.12.04.17.01.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 17:01:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dino Farinacci In-Reply-To: Date: Fri, 4 Dec 2015 17:01:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <143E50D2-ACA1-442A-A997-638D56055E66@gmail.com> References: <20151130124204.32281.43652.idtracker@ietfa.amsl.com> To: LISP mailing list list X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [lisp] Expiration impending: 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, 05 Dec 2015 01:01:20 -0000 I have not received a response. Does silence mean consent? Chairs? Dino > On Nov 30, 2015, at 10:04 AM, Dino Farinacci = wrote: >=20 > Folks, I presented this at many WG meetings and felt it is ready for = working group document. I asked this in Yokohama and want to follow-up = now on the list. >=20 > Since the individual submission is about to expire, I am wonder if I = can resubmit it as draft-ietf-lisp-signal-free-multicast-00? >=20 > Chairs? >=20 > Dino >=20 >> Begin forwarded message: >>=20 >> From: IETF Secretariat >> Date: November 30, 2015 at 4:42:04 AM PST >> To: >> Subject: Expiration impending: = >>=20 >> The following draft will expire soon: >>=20 >> Name: draft-farinacci-lisp-signal-free-multicast >> Title: Signal-Free LISP Multicast >> State: I-D Exists >> Expires: 2015-12-10 (in 1 week, 2 days) >>=20 >=20 From nobody Sat Dec 5 06:12:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECA71AC39A for ; Sat, 5 Dec 2015 06:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 rzKqEiGsfyqA for ; Sat, 5 Dec 2015 06:12:50 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D0E1A701A for ; Sat, 5 Dec 2015 06:12:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F3AAC240719; Sat, 5 Dec 2015 06:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1449324770; bh=VLEYeonnRL5gfa3jO87SuaSbuLDZW0ni/DJzL4WnF4g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PoUR4gaExHtORz+NpaKYmzS31hRGqQIsjVG0i9tvxVoItv34Ui1e7rOAUjgl7tZNo D0gkVAYnKLYGtizbGhSKHcoHjmWmzPVJTp2HHnvN6v+CkieNvC/BtOQF6THl0PQaE5 xG8HRoqbCj186Qshf1xAJXaM+san1U3Pbwy3WD88= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [94.200.20.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E6EC4240474; Sat, 5 Dec 2015 06:12:48 -0800 (PST) To: Dino Farinacci , LISP mailing list list References: <20151130124204.32281.43652.idtracker@ietfa.amsl.com> <143E50D2-ACA1-442A-A997-638D56055E66@gmail.com> From: "Joel M. Halpern" Message-ID: <5662F0DD.208@joelhalpern.com> Date: Sat, 5 Dec 2015 09:12:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <143E50D2-ACA1-442A-A997-638D56055E66@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Expiration impending: 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, 05 Dec 2015 14:12:51 -0000 Unfortunately, silence does not mean consent. So let me send a separate more formal call for adoption. On 12/4/15 8:01 PM, Dino Farinacci wrote: > I have not received a response. Does silence mean consent? Chairs? > > Dino > >> On Nov 30, 2015, at 10:04 AM, Dino Farinacci wrote: >> >> Folks, I presented this at many WG meetings and felt it is ready for working group document. I asked this in Yokohama and want to follow-up now on the list. >> >> Since the individual submission is about to expire, I am wonder if I can resubmit it as draft-ietf-lisp-signal-free-multicast-00? >> >> Chairs? >> >> Dino >> >>> Begin forwarded message: >>> >>> From: IETF Secretariat >>> Date: November 30, 2015 at 4:42:04 AM PST >>> To: >>> Subject: Expiration impending: >>> >>> The following draft will expire soon: >>> >>> Name: draft-farinacci-lisp-signal-free-multicast >>> Title: Signal-Free LISP Multicast >>> State: I-D Exists >>> Expires: 2015-12-10 (in 1 week, 2 days) >>> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Sat Dec 5 06:14:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F61B2A57 for ; Sat, 5 Dec 2015 06:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 5-Emvu4Uo06o for ; Sat, 5 Dec 2015 06:14:21 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCCC1ACDC6 for ; Sat, 5 Dec 2015 06:14:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1C6DD240719 for ; Sat, 5 Dec 2015 06:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1449324861; bh=0CZ91Wbotl7FPRhJd4tiCmlII+pplXa8t7HUk86xG2w=; h=To:From:Subject:Date:From; b=QHKJSA7rI+OaCyfei1PAJMOmc5spUAyE8xGuprg3ZPK6vXKGEC2ycq+FiZdZ2Uc9v Mu85WKZ9KmdAICHyQq6eAfvHzjhnV5JWLGY8kkxn/ykEIy6v9vRKDv178/vnUS6OcD OHrA621o5j8KMNO5xJsEdsmlu61omYDoqJSTIFuw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [94.200.20.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6C9C624017E for ; Sat, 5 Dec 2015 06:14:20 -0800 (PST) To: "lisp@ietf.org" From: "Joel M. Halpern" Message-ID: <5662F139.6080601@joelhalpern.com> Date: Sat, 5 Dec 2015 09:14:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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, 05 Dec 2015 14:14:22 -0000 This is a call for adoption of draft-farinacci-lisp-signal-free-multicast. Please speak up if you support or oppose adoption of this document. It has been presented multiple times to the working group, generally to positive reception as far as I can tell. This call will last two weeks, until CoB 21-December-2015. Yours, Joel From nobody Sun Dec 6 11:01:18 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0606E1B2AA4 for ; Sun, 6 Dec 2015 11:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUL7jFbiAGn1 for ; Sun, 6 Dec 2015 11:01:15 -0800 (PST) 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 B97541B2AA2 for ; Sun, 6 Dec 2015 11:01:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBG24680; Sun, 06 Dec 2015 19:01:12 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 6 Dec 2015 19:01:11 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.81]) by SJCEML703-CHM.china.huawei.com ([169.254.5.130]) with mapi id 14.03.0235.001; Sun, 6 Dec 2015 11:01:07 -0800 From: Richard Li To: "Joel M. Halpern" Thread-Topic: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? Thread-Index: AQHRL2dLQqWnV+OrMU+iNFtbjvvDoJ6+Uh12 Date: Sun, 6 Dec 2015 19:01:06 +0000 Message-ID: References: <5662F139.6080601@joelhalpern.com> In-Reply-To: <5662F139.6080601@joelhalpern.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.566485F8.0113, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 41767f29ff7d30e6837d2131ec7b89bf Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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, 06 Dec 2015 19:01:17 -0000 Support. Renwei > =1B$B:_=1B(B Dec 5, 2015=1B$B!$=1B(B6:14 AM=1B$B!$=1B(B"Joel M. Halpern" = =1B$B=20 > This is a call for adoption of draft-farinacci-lisp-signal-free-multicas= t. > Please speak up if you support or oppose adoption of this document. It h= as been presented multiple times to the working group, generally to positiv= e reception as far as I can tell. >=20 > This call will last two weeks, until CoB 21-December-2015. >=20 > Yours, > Joel >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Dec 6 11:42:25 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CFB1A88E6 for ; Sun, 6 Dec 2015 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLJzkAdOLzE2 for ; Sun, 6 Dec 2015 11:42:21 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A671F1A88DE for ; Sun, 6 Dec 2015 11:42:21 -0800 (PST) Received: by pabfh17 with SMTP id fh17so116172594pab.0 for ; Sun, 06 Dec 2015 11:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=75J8OvuVgBVMiQckbbI6aeFyQSUcfUH2MG9p+qbuInk=; b=V+nOlZTV3qni/h3H9jFfNoiu+R2zakPiZRAgl/5Woounh/Te3VxVV9DF+KKL3zJEhj UD91y5j5i1alXkx/v4HPDpVgtFT/iHUNxnvC1aNR28WrIhDSh3BKnEaogpEnauBQ0Thj zafq2UVRux0CZZ7Vl1gJR7Fb8K7eJZEXh63eN+JGpzVV2cmskNzKlEtFdbgoE0Z32N73 gl6p0vfb6mFtVq6ekMi1b3dTP2ENOISznyNE5HWzGAiuw/XrQKVBeaonk/RVajgfGVuo riJ979GvRauHW8W8P/ygL/aoPrKxwPSJDbvcBE2kSvMbs1/Tt/r977PZ1jgpwE6rheRb huhg== X-Received: by 10.66.251.193 with SMTP id zm1mr37265281pac.154.1449430941296; Sun, 06 Dec 2015 11:42:21 -0800 (PST) Received: from [100.86.54.79] (85.sub-70-197-9.myvzw.com. [70.197.9.85]) by smtp.gmail.com with ESMTPSA id o2sm29793346pap.31.2015.12.06.11.42.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 11:42:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Sun, 6 Dec 2015 11:42:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6E5EDE66-9C85-4285-BC76-5812B05A72AA@gmail.com> References: <5662F139.6080601@joelhalpern.com> To: Richard Li Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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, 06 Dec 2015 19:42:23 -0000 Support=20 What about adding global load balancing to this using similar signal free me= thods --szb > On Dec 6, 2015, at 11:01 AM, Richard Li wrote: >=20 > Support. >=20 > Renwei >=20 >> =E5=9C=A8 Dec 5, 2015=EF=BC=8C6:14 AM=EF=BC=8C"Joel M. Halpern" =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> This is a call for adoption of draft-farinacci-lisp-signal-free-multicas= t. >> Please speak up if you support or oppose adoption of this document. It h= as been presented multiple times to the working group, generally to positive= reception as far as I can tell. >>=20 >> This call will last two weeks, until CoB 21-December-2015. >>=20 >> Yours, >> Joel >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Dec 6 11:45:48 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B371A8908 for ; Sun, 6 Dec 2015 11:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHZhXjf1HP_w for ; Sun, 6 Dec 2015 11:45:45 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831D11A88E8 for ; Sun, 6 Dec 2015 11:45:45 -0800 (PST) Received: by pacej9 with SMTP id ej9so113256172pac.2 for ; Sun, 06 Dec 2015 11:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nj+2qZ70NkXObdGM0/EB0aqae7lkIPmRRqP4AQrPK3s=; b=1E0Sl39Tm6IoDg5vpTfAL3fZd9bjyOGWhPWqsqSIXNL5FW+nuAMwEmxKX2X5cahnKV gKgyll/D/4cCwT7qeFubLn7pJPLqI7yn14eCu/mGeixIvP36EHXU3htH4BdHekUX/7Ld 0KIA8HboX4Jb8Mlfuj0vgRR9Xbfz/+1WcOu7Za8cHs8qOkCLJYx+/GVwTQooepo1iZ// ZyFPUFNo1Xnf9xELeOcxDPrYbUo5TqgAvCfJlA4U2t59nhLevdcjrtfOTw6r1C1+2P0A topejpuE0LzhUYZxhdr2Sz8CWVVRhslIHQIqEdQFZ3LBPwwlrbWOMT72vYBCYcYhBtr+ bvbg== X-Received: by 10.66.240.4 with SMTP id vw4mr37939053pac.9.1449431145236; Sun, 06 Dec 2015 11:45:45 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id sg4sm29777637pac.48.2015.12.06.11.45.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Dec 2015 11:45:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dino Farinacci In-Reply-To: <6E5EDE66-9C85-4285-BC76-5812B05A72AA@gmail.com> Date: Sun, 6 Dec 2015 11:45:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <752526D8-F8DF-4ECE-AF58-5B4F17B97842@gmail.com> References: <5662F139.6080601@joelhalpern.com> <6E5EDE66-9C85-4285-BC76-5812B05A72AA@gmail.com> To: Sharon Barkai X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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, 06 Dec 2015 19:45:47 -0000 > Support=20 > What about adding global load balancing to this using similar signal = free methods That kinda works by default. By putting multiple RLOC-records in a = Map-Reply where each is encoded as an RLE.=20 But with flexible LCAF encoding, you could have a single RLOC-record = made up of an RLE encoding like this: A B, B=E2=80=99 C M Where the ITR replicates to A, B, C, and the group address M. But for = the second replication list entry (B, B=E2=80=99), it could be encoded = as an AFI-list to avoid the multi-record case: Record-1: A B C M Record-2: A B=E2=80=99 C M Dino >=20 > --szb >=20 >> On Dec 6, 2015, at 11:01 AM, Richard Li wrote: >>=20 >> Support. >>=20 >> Renwei >>=20 >>> =E5=9C=A8 Dec 5, 2015=EF=BC=8C6:14 AM=EF=BC=8C"Joel M. Halpern" = =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> This is a call for adoption of = draft-farinacci-lisp-signal-free-multicast. >>> Please speak up if you support or oppose adoption of this document. = It has been presented multiple times to the working group, generally to = positive reception as far as I can tell. >>>=20 >>> This call will last two weeks, until CoB 21-December-2015. >>>=20 >>> Yours, >>> Joel >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Dec 6 16:25:28 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A107C1A8AC7 for ; Sun, 6 Dec 2015 16:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqnvhZjX2JXs for ; Sun, 6 Dec 2015 16:25:25 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3631A8AC4 for ; Sun, 6 Dec 2015 16:25:25 -0800 (PST) Received: by pacej9 with SMTP id ej9so115447399pac.2 for ; Sun, 06 Dec 2015 16:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mpDIw+l0ede3y6Ee6tjtMjBY7tGiMVwqsAGdkf7BT9c=; b=aCSEOHXiu/zoxbaB8xg7ZfPCxwkmMlXRvhQSOqNvk47er99j8R7tkOZnZwzasvjjan 2cxjEpF8VrjJ7RBpbZfpCa14GCT5GqL1eaBxT2vfkSTQ6IsqWn1pjUiFysYvZKjhN+cm +mIWOd8HxFTFmiwHLDeuad7bplLQROpt9RF9zf1Sbog8qgv4zavH6XtEDt5RyVuQvptF Q044mSyDuiZZFB/lI+lNV6dZZtSM7IUHEFnsEffzAVt/oE5frG6Ke+Qs/3LgFqw+K5vY Eu05OZ35f1p3tWf0WCCa0kFn39W0BHcSEwP551tk6ip2o0kyUFQfChY32cgDwMF7kyiy Tknw== X-Received: by 10.66.140.4 with SMTP id rc4mr11286953pab.96.1449447924918; Sun, 06 Dec 2015 16:25:24 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::1f5? ([2001:420:c0c8:1003::1f5]) by smtp.gmail.com with ESMTPSA id m20sm30287044pfi.80.2015.12.06.16.25.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Dec 2015 16:25:24 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=us-ascii From: Florin Coras In-Reply-To: <5662F139.6080601@joelhalpern.com> Date: Mon, 7 Dec 2015 01:25:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D0D5D20-9DD3-4800-A326-8858685F5ADB@gmail.com> References: <5662F139.6080601@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 00:25:26 -0000 Support.=20 Florin > On Dec 5, 2015, at 3:14 PM, Joel M. Halpern = wrote: >=20 > This is a call for adoption of = draft-farinacci-lisp-signal-free-multicast. > Please speak up if you support or oppose adoption of this document. = It has been presented multiple times to the working group, generally to = positive reception as far as I can tell. >=20 > This call will last two weeks, until CoB 21-December-2015. >=20 > Yours, > Joel >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Dec 7 10:13:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405FF1B38E5 for ; Mon, 7 Dec 2015 10:13:34 -0800 (PST) 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 FDCNH8-ykwpz for ; Mon, 7 Dec 2015 10:13:33 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92BD41B38E4 for ; Mon, 7 Dec 2015 10:13:32 -0800 (PST) Received: by lbpu9 with SMTP id u9so32244803lbp.2 for ; Mon, 07 Dec 2015 10:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HyL5vnF8d6004xkZxvGlqt9DlTArNEuAcZtEVLkjP28=; b=OUIrR5IW659qxPfsogIQhlsYJzNrwIvxPhSFCVRfW0FGCO5q/Tz6uEALzouKmvMIve 7HG31yRsoqrMjLCneN7MM1kqC7+gQ2ezdIlJiy9ShMSD7llWf70V2hzv71Sxwoij7Rax i+blAtlUDMm6NrBbJF3j12wBrCft+FFCQNG+MYTZ8FM93EtrbBk6avDkpD7NadLfqmo+ 4AO1ODyuzsAEqowJmh+3ZZPisFTnhwK9c6OlAMkpP8d8nKdD9B0c6iRVbAnAsLdliO2s 1xYtlFSn7JNDnm5ZzIdRvd7v2bSozEPOZRUM/ds3qwYvr5IIgIJUWLM9SYwM291xBu2F 2mLA== MIME-Version: 1.0 X-Received: by 10.112.198.131 with SMTP id jc3mr11972018lbc.129.1449512010739; Mon, 07 Dec 2015 10:13:30 -0800 (PST) Received: by 10.25.91.208 with HTTP; Mon, 7 Dec 2015 10:13:30 -0800 (PST) Date: Mon, 7 Dec 2015 19:13:30 +0100 Message-ID: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= To: "lisp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 18:13:34 -0000 On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern wrote: > This is a call for adoption of draft-farinacci-lisp-signal-free-multicast. > Please speak up if you support or oppose adoption of this document. It has > been presented multiple times to the working group, generally to positive > reception as far as I can tell. support -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Mon Dec 7 11:03:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AF21B39C9 for ; Mon, 7 Dec 2015 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 k9TZf-mgqbsJ for ; Mon, 7 Dec 2015 11:03:50 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4291B39C0 for ; Mon, 7 Dec 2015 11:03:50 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-6e-5665d811c122 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 4C.65.32102.118D5665; Mon, 7 Dec 2015 20:03:45 +0100 (CET) Received: from [10.155.105.13] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.248.2; Mon, 7 Dec 2015 14:03:48 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_580AD61B-B2B6-4620-8CCC-84789B24EBDA" MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Wassim Haddad In-Reply-To: Date: Mon, 7 Dec 2015 11:03:57 -0800 Message-ID: References: To: "lisp@ietf.org" X-Mailer: Apple Mail (2.3096.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyuXRPuK7gjdQwg20nZS2mnFV3YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG98dz2Ao+yFRMvTKBrYFxjWQXIyeHhICJxN7r1xkhbDGJC/fW s3UxcnEICRxhlOg4eZcdwlnLKLFk8R92kCpmgSSJR1c/MIHYvAIGEmemnmEGsYUFPCS69q5m BbHZgOJfl58FszkFAiVeXfvKBmKzCKhI/Nn2gwVijp7Eo9u9QL0cQHPsJdobk0DCQgIBEq1P l4IdJCKgLHG+r4UZ4jh5iZ8rG5ggatQlptyawDKBUWAWkotmIbkIIq4tsWzhayCbA8jWlFi/ Sx9VGMTWkGidM5d9ASPbKkaO0uKCnNx0I8NNjMBgPSbB5riDcW+v5yFGAQ5GJR5eg+upYUKs iWXFlbmHGCU4mJVEeGUzgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5GRkYGIQE0hNLUrNTUwtS i2CyTBycUg2MTGsc/i25lhtx2sJx05mpykpTPgd+SEriuT+HjaNk86TPfqUybx1Zj3UvvaHY UHY/b1dwwkXPRKX3STtPxFvfNtj43i5K8fVhk10b6nfc4E6r4fC7orVrf9Xp+LOhhW9EV600 qbtVNXv+geovU7iXfjvZyHE1aXEGj9f6K0vrNbaZiPlkrzxaq8RSnJFoqMVcVJwIAM1eM3JS AgAA Archived-At: Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 19:03:52 -0000 --Apple-Mail=_580AD61B-B2B6-4620-8CCC-84789B24EBDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 > On Dec 7, 2015, at 10:13, Roger J=C3=B8rgensen = wrote: >=20 > On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern = wrote: >> This is a call for adoption of = draft-farinacci-lisp-signal-free-multicast. >> Please speak up if you support or oppose adoption of this document. = It has >> been presented multiple times to the working group, generally to = positive >> reception as far as I can tell. >=20 > support >=20 >=20 >=20 > --=20 >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_580AD61B-B2B6-4620-8CCC-84789B24EBDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" +1





On Dec 7, 2015, at 10:13, Roger J=C3=B8rgensen <rogerj@gmail.com> = wrote:

On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern <jmh@joelhalpern.com>= wrote:
This is a = call for adoption  of = draft-farinacci-lisp-signal-free-multicast.
Please speak = up if you support or oppose adoption of this document.  It has
been presented multiple times to the working group, generally = to positive
reception as far as I can tell.

support



--

Roger Jorgensen =           | = ROJO9-RIPE
rogerj@gmail.com =          | - IPv6 is The = Key!
http://www.jorgensen.no   | roger@jorgensen.no

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

= --Apple-Mail=_580AD61B-B2B6-4620-8CCC-84789B24EBDA-- From nobody Tue Dec 8 00:02:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E751A007C for ; Tue, 8 Dec 2015 00:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 v1TQ9_zOBYGU for ; Tue, 8 Dec 2015 00:02:13 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03491A006D for ; Tue, 8 Dec 2015 00:02:12 -0800 (PST) Received: by wmww144 with SMTP id w144so170733578wmw.1 for ; Tue, 08 Dec 2015 00:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HPPgyMMA0TjrLliDY7mIkItwmSNKJw9NNkL22rdSk68=; b=zKaL86rmzXq9sry6Dw+pzhYIvlFnNzB0WmBV6dlCSd+DatMsvn3VYiIZVrMmS7zqq7 z7zEi6zqJp0RRzJeDjJzEDGOpzxiCa70U5V+s/vx3uF4R/AmgpN4n9XdFldRQ6Mxh+6/ SUIOBUfdetkarZhAv75XIBFrFTS/kpirBBxN79lK3DHti5Y71TEp5b2zuQLiKHCnEO4q QpaGxq6wI44kuOHNLe8anAjSBO+QyK/vs5JOAieqa+8osEbQamunoKDkh/Tp2txx0+AS Ev8rBc6GCv472bD+smtV7IOnoDrMq8p23HOMCjMljD8JewheCxQ910UwjbbLpLEmMgnE 2zBg== X-Received: by 10.28.188.84 with SMTP id m81mr24509573wmf.38.1449561730570; Tue, 08 Dec 2015 00:02:10 -0800 (PST) Received: from eduroam-173a.sophia.inria.fr (eduroam-173a.sophia.inria.fr. [193.51.208.173]) by smtp.gmail.com with ESMTPSA id gj2sm1741511wjb.40.2015.12.08.00.02.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 00:02:09 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Tue, 8 Dec 2015 09:02:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wassim Haddad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 08:02:14 -0000 +1 Damien Saucez=20 On 07 Dec 2015, at 20:03, Wassim Haddad = wrote: > +1 >=20 >=20 >=20 >=20 >=20 >> On Dec 7, 2015, at 10:13, Roger J=F8rgensen wrote: >>=20 >> On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern = wrote: >>> This is a call for adoption of = draft-farinacci-lisp-signal-free-multicast. >>> Please speak up if you support or oppose adoption of this document. = It has >>> been presented multiple times to the working group, generally to = positive >>> reception as far as I can tell. >>=20 >> support >>=20 >>=20 >>=20 >> --=20 >>=20 >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Dec 8 08:24:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF01B2FB9 for ; Tue, 8 Dec 2015 08:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.51 X-Spam-Level: * X-Spam-Status: No, score=1.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.488, MISSING_HEADERS=1.021, 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 I8NXo5K8xpje for ; Tue, 8 Dec 2015 08:24:53 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7FC1B2E28 for ; Tue, 8 Dec 2015 08:24:53 -0800 (PST) Received: by qgeb1 with SMTP id b1so23630819qge.1 for ; Tue, 08 Dec 2015 08:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc :content-type; bh=JXl/cvjn1Ar3JDo1hqu10dWKmjhj2pQyW2kG5P70SBc=; b=p1UBDLWUC0+KULMkXMhNG4treQwRehajGIfcm5Rup4EHtVPf7DB80yegn/G6V3yBX6 KuU0gaSpw9q/ehdYcAXeutKJJQSSszqj/FPFhQR2MG+TtybBGL3jPZPhscvlH6ejWBYt fSDMGqSSD3J/r2fEj6TDQ7UoFBc2iiIG59OHnf33+qotcL69mOdS4MsZF+i1lFFZHPcl 0OYwSw5IOaGOjPr1TrYo1eLqs68lN1+et05zqbzR2QPQ1zhDPHeZsAahADdW4fH1YEIX JTDQ+1rh6KalqbfIL8XeMXSKtJa7ZtH/dMuVavFgCDn0R5zVUft0+VqCIPQMCrtwVs2e kGxQ== X-Received: by 10.140.97.229 with SMTP id m92mr626153qge.22.1449591892377; Tue, 08 Dec 2015 08:24:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kiran Makhijani Date: Tue, 08 Dec 2015 16:24:43 +0000 Message-ID: Cc: LISP mailing list list Content-Type: multipart/alternative; boundary=001a113a61ced08a310526656979 Archived-At: Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 16:24:54 -0000 --001a113a61ced08a310526656979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support. Kiran On Tue, Dec 8, 2015 at 12:02 AM Damien Saucez wrote: > +1 > > Damien Saucez > On 07 Dec 2015, at 20:03, Wassim Haddad > wrote: > > > +1 > > > > > > > > > > > >> On Dec 7, 2015, at 10:13, Roger J=C3=B8rgensen wrot= e: > >> > >> On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern > wrote: > >>> This is a call for adoption of > draft-farinacci-lisp-signal-free-multicast. > >>> Please speak up if you support or oppose adoption of this document. > It has > >>> been presented multiple times to the working group, generally to > positive > >>> reception as far as I can tell. > >> > >> support > >> > >> > >> > >> -- > >> > >> Roger Jorgensen | ROJO9-RIPE > >> rogerj@gmail.com | - IPv6 is The Key! > >> http://www.jorgensen.no | roger@jorgensen.no > >> > >> _______________________________________________ > >> lisp mailing list > >> lisp@ietf.org > >> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --=20 Kiran --001a113a61ced08a310526656979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.
Kiran

On Tue, Dec 8, 2015 at 12:02 AM Damien Saucez <damien.saucez@gmail.com> wrote:
+1

Damien Saucez
On 07 Dec 2015, at 20:03, Wassim Haddad <wassim.haddad@ericsson.com> wrote:<= br>
> +1
>
>
>
>
>
>> On Dec 7, 2015, at 10:13, Roger J=C3=B8rgensen <rogerj@gmail.com> wrote:
>>
>> On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern <jmh@joelhalpern.com> wrot= e:
>>> This is a call for adoption=C2=A0 of draft-farinacci-lisp-sign= al-free-multicast.
>>> Please speak up if you support or oppose adoption of this docu= ment.=C2=A0 It has
>>> been presented multiple times to the working group, generally = to positive
>>> reception as far as I can tell.
>>
>> support
>>
>>
>>
>> --
>>
>> Roger Jorgensen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ROJO9-RI= PE
>> rogerj@gmail= .com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | - IPv6 is The Key!
>> http://www.jorgensen.no=C2=A0 =C2=A0| roger@jorgensen.no
>>
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp >
> _______________________________________________
> lisp mailing list
> lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--
Kiran
--001a113a61ced08a310526656979-- From nobody Tue Dec 8 09:51:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFED1A0461 for ; Tue, 8 Dec 2015 09:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg7DxvywsJ0h for ; Tue, 8 Dec 2015 09:51:52 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAD41A0469 for ; Tue, 8 Dec 2015 09:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=565; q=dns/txt; s=iport; t=1449597112; x=1450806712; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=LDAt1yN2fr9T+VoBzcI4eb/kytzTID2OxQ6a+//SRIY=; b=elU1PdzMPpoL65NgHc3qQhXl5iZN4JWzEHPwAHuInrjfZLWoIDpuB1yz Xf/3zGRloieQTNllklhL3mcX9bUwQxlaathqBQ5BAdlUNyqwxqJpKNRmS vmc7A3eYgJy+SancIDs3zurmp+Jm3vz//w6sFjw2C33pZY2UXEnb0zg4Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgDqF2dW/5xdJa1egzpTbr1AAQ1ag?= =?us-ascii?q?RQXCoVtAoE+OBQBAQEBAQEBgQqENQEBBAEBARoGFTYKEQsYAgIFFgsCAgkDAgE?= =?us-ascii?q?CARUwEwYCAQGIKw2vNpBwAQEBAQEFAQEBAQEaBIEBhVOEfYUnglCBRAEEjh+EW?= =?us-ascii?q?INqjTyBW4RDgwOTTB8BAUKEJR00hW8BAQE?= X-IronPort-AV: E=Sophos;i="5.20,400,1444694400"; d="scan'208";a="53741459" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2015 17:51:51 +0000 Received: from [10.24.65.138] ([10.24.65.138]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tB8Hpp6M008426 for ; Tue, 8 Dec 2015 17:51:51 GMT To: lisp@ietf.org References: <5662F139.6080601@joelhalpern.com> From: Fabio Maino Message-ID: <566718B6.6090507@cisco.com> Date: Tue, 8 Dec 2015 09:51:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5662F139.6080601@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 17:51:57 -0000 support. Fabio On 12/5/15 6:14 AM, Joel M. Halpern wrote: > This is a call for adoption of > draft-farinacci-lisp-signal-free-multicast. > Please speak up if you support or oppose adoption of this document. > It has been presented multiple times to the working group, generally > to positive reception as far as I can tell. > > This call will last two weeks, until CoB 21-December-2015. > > Yours, > Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Dec 9 02:37:07 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685451A01CB for ; Wed, 9 Dec 2015 02:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m_4f_EoehfX for ; Wed, 9 Dec 2015 02:37:03 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 000A91A01A3 for ; Wed, 9 Dec 2015 02:37:02 -0800 (PST) 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 tB98rdjg013721 for ; Wed, 9 Dec 2015 09:53:39 +0100 Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id 1C728836 for ; Wed, 9 Dec 2015 11:37:01 +0100 (CET) Received: by lfdl133 with SMTP id l133so31033867lfd.2 for ; Wed, 09 Dec 2015 02:37:00 -0800 (PST) X-Received: by 10.25.21.151 with SMTP id 23mr1497450lfv.165.1449657420114; Wed, 09 Dec 2015 02:37:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.124.202 with HTTP; Wed, 9 Dec 2015 02:36:40 -0800 (PST) In-Reply-To: <5662F139.6080601@joelhalpern.com> References: <5662F139.6080601@joelhalpern.com> From: Alberto Rodriguez-Natal Date: Wed, 9 Dec 2015 11:36:40 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11406aae92750e052674abd5 Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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 Dec 2015 10:37:06 -0000 --001a11406aae92750e052674abd5 Content-Type: text/plain; charset=UTF-8 Support On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern wrote: > This is a call for adoption of draft-farinacci-lisp-signal-free-multicast. > Please speak up if you support or oppose adoption of this document. It > has been presented multiple times to the working group, generally to > positive reception as far as I can tell. > > This call will last two weeks, until CoB 21-December-2015. > > Yours, > Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a11406aae92750e052674abd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support

On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern <jmh@j= oelhalpern.com> wrote:
This= is a call for adoption=C2=A0 of draft-farinacci-lisp-signal-free-multicast= .
Please speak up if you support or oppose adoption of this document.=C2=A0 I= t has been presented multiple times to the working group, generally to posi= tive reception as far as I can tell.

This call will last two weeks, until CoB 21-December-2015.

Yours,
Joel

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

--001a11406aae92750e052674abd5-- From nobody Fri Dec 11 01:35:08 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F81ACE51 for ; Fri, 11 Dec 2015 01:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMzkpmiWeVh7 for ; Fri, 11 Dec 2015 01:35:05 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F96B1A8732 for ; Fri, 11 Dec 2015 01:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3576; q=dns/txt; s=iport; t=1449826505; x=1451036105; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=agVt3G8FpomR1TlLk+jxoL6nSTuTDL4RxitWG9Y/dBM=; b=MV8TsIig8pmcmlsE8+hGjSXjttUv1MVOawfsHlzqh6RcsLPRI4flPeBc EYhg2Ge+pX1to3WqRrGq06X56T3OmxFH7kc2wTb7Xl0x9KQGRKU/d2JFx ZXkQW7AHmlqZyM+DLQ30xRR3E/1vZAOprshencJXjm6MHuIdojfFEUrs0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgBml2pW/4kNJK1eDoMsU24GvSgBD?= =?us-ascii?q?YFiFwEJhW4CgS04FAEBAQEBAQGBCoQ1AQEEAQEBGlELEAIBCAQ7BycLFBECBA4?= =?us-ascii?q?FiC8NvnYBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWgg+CboUIgx6BGgWWcQGNQ?= =?us-ascii?q?4FbhEWWbgEfAQFCg0Y+coRQgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,412,1444694400"; d="scan'208,217";a="215663686" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2015 09:35:04 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBB9Z4dr010660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Dec 2015 09:35:04 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Dec 2015 03:35:03 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 11 Dec 2015 03:35:03 -0600 From: "Victor Moreno (vimoreno)" To: Alberto Rodriguez-Natal Thread-Topic: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? Thread-Index: AQHRL2dBkiV2A7LrYUasfVVEwxMaU57C4MAAgAMTdAA= Date: Fri, 11 Dec 2015 09:35:03 +0000 Message-ID: <26B9AAFE-38F5-4789-80FC-D2F1EDF544D0@cisco.com> References: <5662F139.6080601@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.81.105] Content-Type: multipart/alternative; boundary="_000_26B9AAFE38F5478980FCD2F1EDF544D0ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast? 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, 11 Dec 2015 09:35:07 -0000 --_000_26B9AAFE38F5478980FCD2F1EDF544D0ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support -v On Dec 9, 2015, at 2:36 AM, Alberto Rodriguez-Natal > wrote: Support On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern > wrote: This is a call for adoption of draft-farinacci-lisp-signal-free-multicast. Please speak up if you support or oppose adoption of this document. It has= been presented multiple times to the working group, generally to positive = reception as far as I can tell. This call will last two weeks, until CoB 21-December-2015. Yours, Joel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_000_26B9AAFE38F5478980FCD2F1EDF544D0ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Support

-v

On Dec 9, 2015, at 2:36 AM, Alberto Rodriguez-Natal <arnatal@ac.upc.edu> wr= ote:

Support

On Sat, Dec 5, 2015 at 3:14 PM, Joel M. Halpern = <jmh= @joelhalpern.com> wrote:
This is a call for adoption  of draft-farinacci-lisp-signal-free-multi= cast.
Please speak up if you support or oppose adoption of this document.  I= t has been presented multiple times to the working group, generally to posi= tive reception as far as I can tell.

This call will last two weeks, until CoB 21-December-2015.

Yours,
Joel

_______________________________________________
lisp mailing list
lisp@ietf.org=
https://www.ietf.org/mailman/listinfo/lisp<= br class=3D"">

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

--_000_26B9AAFE38F5478980FCD2F1EDF544D0ciscocom_-- From nobody Fri Dec 11 05:03:05 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FAD1A8A96; Fri, 11 Dec 2015 05:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPAUW6K9hxHM; Fri, 11 Dec 2015 05:03:00 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932651A8A9E; Fri, 11 Dec 2015 05:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8539; q=dns/txt; s=iport; t=1449838980; x=1451048580; h=to:from:subject:cc:message-id:date:mime-version; bh=41DCR/r+RkB97rQ+LZfsD/JQdGDTU1RxIBzj3Cg2aco=; b=jGtkwHii61Nwqkd+INwtKnGfqwqxvsLOyetKt9GsVJ5BHYRtac3MFdfJ E/xEmbQaCcdBgrMUcpPZm8XZz33Rmus6cAgwYZqeSH2V/b3U8vtXGIgB0 cMaOagWek/raXUgmPTTVyZoY0UywVd9yMLtGtmftuNA8l+b3RMnZ019vH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQBoyGpW/xbLJq1ehA1uuxaCGQENg?= =?us-ascii?q?WIXAQuFbIFoFAEBAQEBAQGBCoQ3JyYwPCECEQJZBgIBAYgrDaxPkgEBAQEHAQE?= =?us-ascii?q?BAQEehlaJP0aCNToTgTYFjTOJP4U1iA+BW0mHAY94g3MfAQFChAU9NAGFVgEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.20,413,1444694400"; d="scan'208,217";a="633691100" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2015 13:02:57 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBBD2uT3028742; Fri, 11 Dec 2015 13:02:56 GMT To: lisp@ietf.org From: Benoit Claise Message-ID: <566AC980.10909@cisco.com> Date: Fri, 11 Dec 2015 14:02:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070601090605050801030805" Archived-At: Cc: draft-ietf-lisp-yang@ietf.org, "yang-coord@ietf.org" Subject: [lisp] YANG data models in LISP: extraction and compilation feedback 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, 11 Dec 2015 13:03:02 -0000 This is a multi-part message in MIME format. --------------070601090605050801030805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I looked at the YANG model in the LISP WG document, from a compilation point of view (NOT a YANG design point of view): https://tools.ietf.org/html/draft-ietf-lisp-yang-00 First of, we can't extract your YANG models from the draft. Here are the extraction error messages: xym.py draft-ietf-lisp-yang-00.txt ERROR: 'draft-ietf-lisp-yang-00.txt', Line 138 - Yang module 'ietf-lisp' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1193 - Yang module 'lisp-itr' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1630 - Yang module 'lisp-etr' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2363 - Yang module 'lisp-map-server' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2638 - Yang module 'lisp-map-resolver' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3291 - Yang module 'lisp-pitr' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3548 - Yang module 'lisp-petr' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3651 - Yang module 'lisp-address-types' with no and not starting with 'example-' As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct way to use is The "" tag SHOULD be followed by a string identifying the file name specified in Section 5.2 of [I-D.ietf-netmod-rfc6020bis ]. The following example is for the '2010-01-18' revision of the 'ietf-foo' module: file"ietf-foo@2010-01-18.yang" module ietf-foo { // ... revision 2010-01-18 { description "Latest revision"; reference "RFC XXXX"; } // ... } Note that the example YANG models should use the "example-" prefix, and no Now, if I extract those modules anyway, you have some compilation errors: pyang --ietf *.yang lisp-address-types.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" lisp-etr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" lisp-itr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" lisp-map-resolver.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" lisp-map-server.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" lisp-petr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" lisp-pitr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" Once you correct the extraction issues, the YANG models, along with some remaining compilation errors, will appear at http://www.claise.be/IETFYANGPageCompilation.html Finally, note that www.yangvalidator.com is your friend._ _ Regards, Benoit --------------070601090605050801030805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

I looked at the YANG model in the LISP WG document, from a compilation point of view (NOT a YANG design point of view):
    https://tools.ietf.org/html/draft-ietf-lisp-yang-00

First of, we can't extract your YANG models from the draft.

Here are the extraction error messages:
xym.py draft-ietf-lisp-yang-00.txt
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 138 - Yang module 'ietf-lisp' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1193 - Yang module 'lisp-itr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1630 - Yang module 'lisp-etr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2363 - Yang module 'lisp-map-server' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2638 - Yang module 'lisp-map-resolver' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3291 - Yang module 'lisp-pitr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3548 - Yang module 'lisp-petr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3651 - Yang module 'lisp-address-types' with no <CODE BEGINS> and not starting with 'example-'

As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct way to use <CODE BEGINS> <CODE ENDS> is 

   The "<CODE BEGINS>" tag SHOULD be followed by a string identifying
   the file name specified in Section 5.2 of
   [I-D.ietf-netmod-rfc6020bis].  The following example is for the
   '2010-01-18' revision of the 'ietf-foo' module:

     <CODE BEGINS> file "ietf-foo@2010-01-18.yang"
       module ietf-foo {
         // ...
         revision 2010-01-18 {
           description "Latest revision";
           reference "RFC XXXX";
         }
         // ...
       }
     <CODE ENDS>

Note that the example YANG models should use the "example-" prefix, and no <CODE BEGINS> <CODE ENDS>


Now, if I extract those modules anyway, you have some compilation errors:
pyang --ietf *.yang
lisp-address-types.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-etr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-itr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-map-resolver.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-map-server.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-petr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-pitr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"

Once you correct the extraction issues, the YANG models, along with some remaining compilation errors, will appear at http://www.claise.be/IETFYANGPageCompilation.html

Finally, note that www.yangvalidator.com is your friend.
Regards, Benoit --------------070601090605050801030805-- From nobody Thu Dec 17 21:18:33 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 498A61B332E; Thu, 17 Dec 2015 21:18:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151218051831.12149.39755.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 21:18:31 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-yang-01.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, 18 Dec 2015 05:18:31 -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 Configuration YANG Model Authors : Vina Ermagan Alberto Rodriguez-Natal Florin Coras Carl Moberg Albert Cabellos-Aparicio Fabio Maino Filename : draft-ietf-lisp-yang-01.txt Pages : 82 Date : 2015-12-17 Abstract: This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 17 21:27:13 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047C31B3345; Thu, 17 Dec 2015 21:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTr5-p2EPC2N; Thu, 17 Dec 2015 21:27:08 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839421B3344; Thu, 17 Dec 2015 21:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11554; q=dns/txt; s=iport; t=1450416428; x=1451626028; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mRNDGgxqi7Dd1WN0Pl2w335aa/XrGp3YgvFAzJvKu+g=; b=grIJO7YRlDDJ+0IzwA1dNCotpECEJSSaytglko1xhiBcQNjng0mK8s9L cN0V1L/7NIm3XhG6RR+x5LarmfP7kpYDD2BlEuG6qMwpIf059SzdzNPuI KBHoev9K/3nD4929ZuxyFOBgIAMP/IJyo/9pjVmVx4i1m81HpUqLDa7ci 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgCDmHNW/5xdJa1egm5MUm0Guz2CG?= =?us-ascii?q?QENgWIjhWoCgTs4FAEBAQEBAQGBCoQ0AQEBBEkwEAIBCBEDAQIoBzIUCQgCBAE?= =?us-ascii?q?NBYgvDr08AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZWhH6EQjkNEYQnBY02iUcBh?= =?us-ascii?q?TiID4FcSZcEg3MBIAEBQoQEcgGDYYEIAQEB?= X-IronPort-AV: E=Sophos; i="5.20,444,1444694400"; d="scan'208,217"; a="54516761" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2015 05:27:07 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tBI5R7Bj016981 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Dec 2015 05:27:07 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Dec 2015 23:27:06 -0600 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1104.009; Thu, 17 Dec 2015 23:27:06 -0600 From: "Vina Ermagan (vermagan)" To: "Benoit Claise (bclaise)" , "lisp@ietf.org" Thread-Topic: [lisp] YANG data models in LISP: extraction and compilation feedback Thread-Index: AQHRNBRJF9on5tG5FUiS3MnuV81WLp7QH8aA Date: Fri, 18 Dec 2015 05:27:06 +0000 Message-ID: References: <566AC980.10909@cisco.com> In-Reply-To: <566AC980.10909@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.60.136] Content-Type: multipart/alternative; boundary="_000_D298D8247245Cvermaganciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-lisp-yang@ietf.org" , "yang-coord@ietf.org" Subject: Re: [lisp] YANG data models in LISP: extraction and compilation feedback 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, 18 Dec 2015 05:27:11 -0000 --_000_D298D8247245Cvermaganciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Beniot, Thanks for the notification. The errors below should be fixed in the new re= vision draft-ietf-lisp-yang-01 published today. I also tested the new versi= on with yangvalidator, and all seems to be fine. Thank you, Vina From: "Benoit Claise (bclaise)" > Date: Friday, December 11, 2015 5:02 AM To: "lisp@ietf.org" > Cc: "draft-ietf-lisp-yang@ietf.org" <= draft-ietf-lisp-yang@ietf.org>, "yang= -coord@ietf.org" > Subject: [lisp] YANG data models in LISP: extraction and compilation feedba= ck Dear all, I looked at the YANG model in the LISP WG document, from a compilation poin= t of view (NOT a YANG design point of view): https://tools.ietf.org/html/draft-ietf-lisp-yang-00 First of, we can't extract your YANG models from the draft. Here are the extraction error messages: xym.py draft-ietf-lisp-yang-00.txt ERROR: 'draft-ietf-lisp-yang-00.txt', Line 138 - Yang module 'ietf-lisp' wi= th no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1193 - Yang module 'lisp-itr' wi= th no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1630 - Yang module 'lisp-etr' wi= th no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2363 - Yang module 'lisp-map-ser= ver' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2638 - Yang module 'lisp-map-res= olver' with no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3291 - Yang module 'lisp-pitr' w= ith no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3548 - Yang module 'lisp-petr' w= ith no and not starting with 'example-' ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3651 - Yang module 'lisp-address= -types' with no and not starting with 'example-' As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05= , the correct way to use is The "" tag SHOULD be followed by a string identifying the file name specified in Section 5.2 of [I-D.ietf-netmod-rfc6020bis]. The following example is= for the '2010-01-18' revision of the 'ietf-foo' module: file "ietf-foo@2010-01-18.yang" module ietf-foo { // ... revision 2010-01-18 { description "Latest revision"; reference "RFC XXXX"; } // ... } Note that the example YANG models should use the "example-" prefix, and no = Now, if I extract those modules anyway, you have some compilation errors: pyang --ietf *.yang lisp-address-types.yang:1: warning: RFC 6087: 4.1: the module name should s= tart with one of the strings "ietf-" or "iana-" lisp-etr.yang:1: warning: RFC 6087: 4.1: the module name should start with = one of the strings "ietf-" or "iana-" lisp-itr.yang:1: warning: RFC 6087: 4.1: the module name should start with = one of the strings "ietf-" or "iana-" lisp-map-resolver.yang:1: warning: RFC 6087: 4.1: the module name should st= art with one of the strings "ietf-" or "iana-" lisp-map-server.yang:1: warning: RFC 6087: 4.1: the module name should star= t with one of the strings "ietf-" or "iana-" lisp-petr.yang:1: warning: RFC 6087: 4.1: the module name should start with= one of the strings "ietf-" or "iana-" lisp-pitr.yang:1: warning: RFC 6087: 4.1: the module name should start with= one of the strings "ietf-" or "iana-" Once you correct the extraction issues, the YANG models, along with some re= maining compilation errors, will appear at http://www.claise.be/IETFYANGPageCompilation.html Finally, note that www.yangvalidator.com is y= our friend. Regards, Benoit --_000_D298D8247245Cvermaganciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <949F34B59D751D4F96FEB43A7B292537@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Beniot,

Thanks for the notification. The errors below should be fixed in the n= ew revision draft-ietf-lisp-yang-01 published today. I also tested the new = version with yangvalidator, and all seems to be fine.

Thank you,
Vina

From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Friday, December 11, 2015 5:0= 2 AM
To: "lisp@ietf.org" <lisp@i= etf.org>
Cc: "draft-ietf-lisp-yang@ietf.org" <draft-ietf-lisp-yang@ietf.org= >, "yang-coord@ietf.org&= quot; <yang-coord@ietf.org>
Subject: [lisp] YANG data models in= LISP: extraction and compilation feedback

Dear all,

I looked at the YANG model in the LISP WG document, from a compilation poin= t of view (NOT a YANG design point of view):
    https://tools.ietf.o= rg/html/draft-ietf-lisp-yang-00

First of, we can't extract your YANG models from the draft.

Here are the extraction error messages:
xym.py draft-ietf-lisp-yang-00.txt
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 138 - Yang module 'ietf-lisp' wi= th no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1193 - Yang module 'lisp-itr' wi= th no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1630 - Yang module 'lisp-etr' wi= th no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2363 - Yang module 'lisp-map-ser= ver' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2638 - Yang module 'lisp-map-res= olver' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3291 - Yang module 'lisp-pitr' w= ith no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3548 - Yang module 'lisp-petr' w= ith no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3651 - Yang module 'lisp-address= -types' with no <CODE BEGINS> and not starting with 'example-'

As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correc= t way to use <CODE BEGINS> <CODE ENDS> is 

   The "<CODE BEGINS>" tag SHOULD be=
 followed by a string identifying
   the file name specified in Section 5.2 of
   [I-D.ietf-netmod-rfc6020bis].  The follo=
wing example is for the
   '2010-01-18' revision of the 'ietf-foo' module:

     <CODE BEGINS> file "ietf-foo@2010-01-18.yang"
       module ietf-foo {
         // ...
         revision 2010-01-18 {
           description "Latest revision";
           reference "RFC XXXX";
         }
         // ...
       }
     <CODE ENDS>

Note that the example YANG models should use the "example-" prefi= x, and no <CODE BEGINS> <CODE ENDS>


Now, if I extract those modules anyway, you have some compilation errors: pyang --ietf *.yang
lisp-address-types.yang:1: warning: RFC 6087: 4.1: the module name should s= tart with one of the strings "ietf-" or "iana-"
lisp-etr.yang:1: warning: RFC 6087: 4.1: the module name should start with = one of the strings "ietf-" or "iana-"
lisp-itr.yang:1: warning: RFC 6087: 4.1: the module name should start with = one of the strings "ietf-" or "iana-"
lisp-map-resolver.yang:1: warning: RFC 6087: 4.1: the module name should st= art with one of the strings "ietf-" or "iana-"
lisp-map-server.yang:1: warning: RFC 6087: 4.1: the module name should star= t with one of the strings "ietf-" or "iana-"
lisp-petr.yang:1: warning: RFC 6087: 4.1: the module name should start with= one of the strings "ietf-" or "iana-"
lisp-pitr.yang:1: warning: RFC 6087: 4.1: the module name should start with= one of the strings "ietf-" or "iana-"

Once you correct the extraction issues, the YANG models, along with some re= maining compilation errors, will appear at http://www.claise.be/IETFYANGPageCompilation.html

Finally, note that www.yangvalidator.com is your friend.

Regards, Benoit
--_000_D298D8247245Cvermaganciscocom_-- From nobody Fri Dec 18 01:24:58 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235CA1B34D5; Fri, 18 Dec 2015 01:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RpYiqLjui1J; Fri, 18 Dec 2015 01:24:51 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805891B34D3; Fri, 18 Dec 2015 01:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13814; q=dns/txt; s=iport; t=1450430691; x=1451640291; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=LeYu2r6EkT/LDuJjbw1pFvj5nHp3kyzF/xIsWcFWUJs=; b=BLGBDedVkuhZ3341kDTZhbY0vnXhaIQxJknXe91L/STqirwYUB7tNEiy /vV9hZsf9J64UxQNQBjCAjIwb1XMwNS2QIKz51K63eTvAYwoVGlHvJoF8 khccdzRjxgoMGBrybzBmDeg2wOBbbLMrP20p8hkX88MkYlVw3jPAIy02H w=; X-IronPort-AV: E=Sophos;i="5.20,445,1444694400"; d="scan'208,217";a="609132378" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2015 09:24:47 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBI9OkRQ021354; Fri, 18 Dec 2015 09:24:47 GMT To: "Vina Ermagan (vermagan)" , "lisp@ietf.org" References: <566AC980.10909@cisco.com> From: Benoit Claise Message-ID: <5673D0DE.1040402@cisco.com> Date: Fri, 18 Dec 2015 10:24:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030507080900050906050405" Archived-At: Cc: "draft-ietf-lisp-yang@ietf.org" , "yang-coord@ietf.org" Subject: Re: [lisp] YANG data models in LISP: extraction and compilation feedback 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, 18 Dec 2015 09:24:55 -0000 This is a multi-part message in MIME format. --------------030507080900050906050405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thanks Vina, Well done. Regards, Benoit. > Hi Beniot, > > Thanks for the notification. The errors below should be fixed in the > new revision draft-ietf-lisp-yang-01 published today. I also tested > the new version with yangvalidator, and all seems to be fine. > > Thank you, > Vina > > From: "Benoit Claise (bclaise)" > > Date: Friday, December 11, 2015 5:02 AM > To: "lisp@ietf.org " > > Cc: "draft-ietf-lisp-yang@ietf.org > " >, "yang-coord@ietf.org > " > > Subject: [lisp] YANG data models in LISP: extraction and compilation > feedback > > Dear all, > > I looked at the YANG model in the LISP WG document, from a > compilation point of view (NOT a YANG design point of view): > https://tools.ietf.org/html/draft-ietf-lisp-yang-00 > > First of, we can't extract your YANG models from the draft. > > Here are the extraction error messages: > xym.py draft-ietf-lisp-yang-00.txt > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 138 - Yang module > 'ietf-lisp' with no and not starting with 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1193 - Yang module > 'lisp-itr' with no and not starting with 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1630 - Yang module > 'lisp-etr' with no and not starting with 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2363 - Yang module > 'lisp-map-server' with no and not starting with > 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2638 - Yang module > 'lisp-map-resolver' with no and not starting with > 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3291 - Yang module > 'lisp-pitr' with no and not starting with 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3548 - Yang module > 'lisp-petr' with no and not starting with 'example-' > ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3651 - Yang module > 'lisp-address-types' with no and not starting with > 'example-' > > As mentioned in > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the > correct way to use is > > The "" tag SHOULD be followed by a string identifying > the file name specified in Section 5.2 of > [I-D.ietf-netmod-rfc6020bis > ]. The following example is for the > '2010-01-18' revision of the 'ietf-foo' module: > > file"ietf-foo@2010-01-18.yang" > module ietf-foo { > // ... > revision 2010-01-18 { > description "Latest revision"; > reference "RFC XXXX"; > } > // ... > } > > > > Note that the example YANG models should use the "example-" > prefix, and no > > > Now, if I extract those modules anyway, you have some compilation > errors: > pyang --ietf *.yang > lisp-address-types.yang:1: warning: RFC 6087: 4.1: the module name > should start with one of the strings "ietf-" or "iana-" > lisp-etr.yang:1: warning: RFC 6087: 4.1: the module name should > start with one of the strings "ietf-" or "iana-" > lisp-itr.yang:1: warning: RFC 6087: 4.1: the module name should > start with one of the strings "ietf-" or "iana-" > lisp-map-resolver.yang:1: warning: RFC 6087: 4.1: the module name > should start with one of the strings "ietf-" or "iana-" > lisp-map-server.yang:1: warning: RFC 6087: 4.1: the module name > should start with one of the strings "ietf-" or "iana-" > lisp-petr.yang:1: warning: RFC 6087: 4.1: the module name should > start with one of the strings "ietf-" or "iana-" > lisp-pitr.yang:1: warning: RFC 6087: 4.1: the module name should > start with one of the strings "ietf-" or "iana-" > > Once you correct the extraction issues, the YANG models, along > with some remaining compilation errors, will appear at > http://www.claise.be/IETFYANGPageCompilation.html > > Finally, note that www.yangvalidator.com is your friend._ > _ > Regards, Benoit > > . --------------030507080900050906050405 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Vina,

Well done.

Regards, Benoit.
Hi Beniot,

Thanks for the notification. The errors below should be fixed in the new revision draft-ietf-lisp-yang-01 published today. I also tested the new version with yangvalidator, and all seems to be fine.

Thank you,
Vina

From: "Benoit Claise (bclaise)" <bclaise@cisco.com>
Date: Friday, December 11, 2015 5:02 AM
To: "lisp@ietf.org" <lisp@ietf.org>
Cc: "draft-ietf-lisp-yang@ietf.org" <draft-ietf-lisp-yang@ietf.org>, "yang-coord@ietf.org" <yang-coord@ietf.org>
Subject: [lisp] YANG data models in LISP: extraction and compilation feedback

Dear all,

I looked at the YANG model in the LISP WG document, from a compilation point of view (NOT a YANG design point of view):
    https://tools.ietf.org/html/draft-ietf-lisp-yang-00

First of, we can't extract your YANG models from the draft.

Here are the extraction error messages:
xym.py draft-ietf-lisp-yang-00.txt
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 138 - Yang module 'ietf-lisp' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1193 - Yang module 'lisp-itr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 1630 - Yang module 'lisp-etr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2363 - Yang module 'lisp-map-server' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 2638 - Yang module 'lisp-map-resolver' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3291 - Yang module 'lisp-pitr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3548 - Yang module 'lisp-petr' with no <CODE BEGINS> and not starting with 'example-'
ERROR: 'draft-ietf-lisp-yang-00.txt', Line 3651 - Yang module 'lisp-address-types' with no <CODE BEGINS> and not starting with 'example-'

As mentioned in https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05, the correct way to use <CODE BEGINS> <CODE ENDS> is 

   The "<CODE BEGINS>" tag SHOULD be followed by a string identifying
   the file name specified in Section 5.2 of
   [I-D.ietf-netmod-rfc6020bis].  The following example is for the
   '2010-01-18' revision of the 'ietf-foo' module:

     <CODE BEGINS> file "ietf-foo@2010-01-18.yang"
       module ietf-foo {
         // ...
         revision 2010-01-18 {
           description "Latest revision";
           reference "RFC XXXX";
         }
         // ...
       }
     <CODE ENDS>

Note that the example YANG models should use the "example-" prefix, and no <CODE BEGINS> <CODE ENDS>


Now, if I extract those modules anyway, you have some compilation errors:
pyang --ietf *.yang
lisp-address-types.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-etr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-itr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-map-resolver.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-map-server.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-petr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
lisp-pitr.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"

Once you correct the extraction issues, the YANG models, along with some remaining compilation errors, will appear at http://www.claise.be/IETFYANGPageCompilation.html

Finally, note that www.yangvalidator.com is your friend.

Regards, Benoit
.

--------------030507080900050906050405-- From nobody Sun Dec 20 06:37:07 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B81B2DB0; Sun, 20 Dec 2015 06:37:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151220143706.23737.72234.idtracker@ietfa.amsl.com> Date: Sun, 20 Dec 2015 06:37:06 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-14.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: Sun, 20 Dec 2015 14:37:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Threats Analysis Authors : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-14.txt Pages : 21 Date : 2015-12-20 Abstract: This document provides 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: https://tools.ietf.org/html/draft-ietf-lisp-threats-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-threats-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 21 08:28:14 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1141A90BD for ; Mon, 21 Dec 2015 08:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 gi_2W9x_f2BA for ; Mon, 21 Dec 2015 08:28:12 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18861A90BB for ; Mon, 21 Dec 2015 08:28:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DE8CD25E333 for ; Mon, 21 Dec 2015 08:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1450715291; bh=47c1s+6wHfmHZOmZmChWZam/5Z9IjBIsw2fRLf0TCbw=; h=To:From:Subject:Date:From; b=Z9owvexY9B4wzeOji7bjrw6QiyDRKE/UJr16NCxyWnHsiD6XIksm/lqcI9oBjL4Of LmXaiyUWLmKRC8spFBufSAAbOs2yhvBo3Bp4M7qeh5bQ34tLi9Bxtq6v90RuznuMcO QMYSv9RGdyoXnYT+ENFvCD3+cAFqHQ6ozJw84+mo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9EE4525DF97 for ; Mon, 21 Dec 2015 08:28:11 -0800 (PST) To: "lisp@ietf.org" From: "Joel M. Halpern" Message-ID: <56782897.8010006@joelhalpern.com> Date: Mon, 21 Dec 2015 11:28:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Adoption of draft-farinacci-lisp-signal-free-multicast 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, 21 Dec 2015 16:28:13 -0000 The call for adoption of this document has ended. There were no objections expressed, and sufficient support, so this document will become a working group document. Thank you, Joel From nobody Mon Dec 21 11:59:07 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D08621ACC7F; Mon, 21 Dec 2015 11:58:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151221195858.12321.21263.idtracker@ietfa.amsl.com> Date: Mon, 21 Dec 2015 11:58:58 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-signal-free-multicast-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 19:58:59 -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 : Signal-Free LISP Multicast Authors : Victor Moreno Dino Farinacci Filename : draft-ietf-lisp-signal-free-multicast-00.txt Pages : 17 Date : 2015-12-21 Abstract: When multicast sources and receivers are active at LISP sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data-plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find de-capsulators at the receiver LISP multicast sites. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 31 09:01:59 2015 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8F1A21A1; Thu, 31 Dec 2015 09:01:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151231170158.16118.42311.idtracker@ietfa.amsl.com> Date: Thu, 31 Dec 2015 09:01:58 -0800 Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, lisp-chairs@ietf.org Subject: [lisp] Last Call: (LISP Threats Analysis) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 17:01:59 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Threats Analysis' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-01-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a threat analysis of the Locator/Identifier Separation Protocol (LISP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ballot/ No IPR declarations have been submitted directly on this I-D.