From nobody Mon Jan 4 04:44:46 2016 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 25D421A8866 for ; Mon, 4 Jan 2016 04:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 zgXUCNEwwtje for ; Mon, 4 Jan 2016 04:44:42 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 722BF1A8865 for ; Mon, 4 Jan 2016 04:44:42 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id f206so171600888wmf.0 for ; Mon, 04 Jan 2016 04:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=jyD1lXDzzFoY+r+bp70Lnt2erzLUQ4aCScPfq0YhskU=; b=Bo2SApSKEYGENysUbOURgBNHuNo5sAxRyMNDAd4XVdgSR/0PkCkd16U6FseRU7OSyS wzU3IIJQlmmUYszgdazBAVY6w0mBWLe8VinG0Zqm/44YSMAlPtC6WHfsW0tf/1+OU5VQ MGgw/5TV6hXNd/7pD5r2Wtt2dQ+GWEEDzmyKu3mNLuO3fMiIEn2wq991J3TxgC0iZEwH 9ZqUB2JZBqJdiC+olCzLAA070BAWOnEHui00HYKYHGPTb+QzHcBvZYHX6VWMPFKMQsfh 8Hm8VHpLo6KybjcrFHlJMZud3NmEaeKURu3p5GKYd6rXDiFrUcnsWJcgMpcR7I/m/hGm lefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version; bh=jyD1lXDzzFoY+r+bp70Lnt2erzLUQ4aCScPfq0YhskU=; b=VcXMkOKg25zUZoi9eF3eHwMzwCdPGah4MNT3UUxQM9iKW56AShATo2nSfHHPhEa7MX w+Vsbprxf2ABy1kx9yYmHoFMa0j4jP5vPLwxJN/76bqqkp3BelL2jl6vKVvbAauqBJrs UQje97AI1L8weWxviArlEuk+kaxANTRm8jE3Q9jj1BuxxcomAy+/70S6c43FXSq1kn+I Xb9mYTdkNTdaXSKe59DwUNXFzPlf2MhZjYBo+99E4Mq2S/ESggIQ9IGOePfoLkEu/oss qTTwDnvxjWcRZjMmsuNdi1hVtJcI2RUvi+Zd45EGLO6gvjNak/7JIWNufUrMfzB7zQ38 hUSg== X-Gm-Message-State: ALoCoQk8r3oYfuaic9UtZb+AuDpeaglaCPaVEUAojhntuDwDoTzk0pFBr7ksuaGy+XT2Ec3Lpcua+LyfJBFPqmTokZaYCTPaBg== X-Received: by 10.194.110.35 with SMTP id hx3mr112725225wjb.0.1451911480989; Mon, 04 Jan 2016 04:44:40 -0800 (PST) Received: from [10.9.1.109] (napsach022.hosting-cea.net. [192.54.209.59]) by smtp.gmail.com with ESMTPSA id qm9sm86048681wjc.39.2016.01.04.04.44.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jan 2016 04:44:39 -0800 (PST) From: Luigi Iannone Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jan 2016 13:44:41 +0100 Message-Id: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct Subject: [lisp] Update Proposed CHarter 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, 04 Jan 2016 12:44:44 -0000 Hi and Happy 2016 to All, time to restart our WG activity in this new year. ;-) We tried to include all comments received via mail and stated during the = last meeting in Japan into an updated charter. Changes are relatively minor, showing that the WG has almost converged = to a proposal. Yet, before pushing the new charter to the IESG for approval, we would = like to have a last short iteration in the WG. Hereafter you can find the updated text.=20 If the text looks good for you, please state so in the mailing list. If you think something is missing or can be improved, please state so in = the mailing list. Thanks=20 Joel and Luigi %%%%%%%% Updated Proposed Charter %%%%%%%%%%%%%%%%%%%%%%%% LISP WG has completed the first set of Experimental RFCs=20 describing the Locator/ID Separation Protocol (LISP).=20 LISP supports a routing architecture which decouples=20 the routing locators and identifiers, thus allowing for=20 efficient aggregation of the routing locator space and=20 providing persistent identifiers in the identifier space.=20 LISP requires no changes to end-systems or to routers=20 that do not directly participate in the LISP deployment.=20 LISP aims for an incrementally deployable protocol.=20 The scope of the LISP techology is recognized to range=20 from unicast and multicast overlays at Layer 2 as well=20 as at Layer 3, including NAT traversal, VPNs, and=20 supporting mobility as a general feature, independently=20 of wheter it is a mobile user or a migrating VM, hence=20 being applicable in both Data Centers and public Internet=20 environments. The LISP WG is chartered to continue work on the LISP base=20 protocol with the main objective to develop a standard=20 solution based on the completed Experimental RFCs and the=20 experience gained from early deployments. This work will include reviewing the existing set of =20 Experimental RFCs and doing the necessary enhancements to =20 support a base set of standards track RFCs. The group will=20 review the current set of Working Group documents to =20 identify potential standards-track documents and do the=20 necessary enhancements to support standards-track. It is =20 recognized that some of the work will continue on the=20 experimental track, though the group is encouraged to move the documents to standards track in support of network use, whereas the work previously was scoped to experimental documents. Beside this main focus, the LISP WG work on the following items: - NAT-Traversal - Mobility - Data-Plane Encryption - Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. - Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These managament methods should be considered for both the data-plane, control-plane, and mapping system components - Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Grops such as NVO3 and SFC. - Alternative Mapping System Design. By extenting LISP with new protocols support it is also necessary to develop the required mapping function extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models and related security extension). From nobody Mon Jan 4 11:49:29 2016 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 4E0421A90CF for ; Mon, 4 Jan 2016 11:49:29 -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 Z7HY7maCKToj for ; Mon, 4 Jan 2016 11:49:28 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 619E21A90CA for ; Mon, 4 Jan 2016 11:49:19 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 65so161866889pff.3 for ; Mon, 04 Jan 2016 11:49:19 -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=B+Li1PsEe9BEbnL36MBPixgSGWLb/8AKB33KUxa+dOk=; b=xQ6xjOzWjzO142Fi1nzJGIpbYEDMVeRXJzkLJbfuvDwvHrvTGOoWA+DDJZ298DveiP xlF9a0CLp5DkVkvP79LXRw1oUyateuBGo+Oi8B8M7aSFVrmtPo2kDU0S6XhcizS/L1S4 8JjxeBZthnMOXJ1joZFAsPeyB86Nr3UB7AqvfabrdhuFS0OVLCSnhEsSz5EM+TS/Dz12 tCnc0MIKQAO0NhO3/RG41p9zRJxGsLrs+fBooGVSOtjX3CO5G7rZgerSPIs6wKt5f9ci ZCSWDVvQ/uo+PB0XHIQJGFgbnRfqw3Ls5zXDVx2hhgjKCn6tHYGUneOXNv7W4NlrZhyx AFyA== X-Received: by 10.98.75.155 with SMTP id d27mr80621277pfj.137.1451936958951; Mon, 04 Jan 2016 11:49:18 -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 n64sm122816059pfi.19.2016.01.04.11.49.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jan 2016 11:49:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> Date: Mon, 4 Jan 2016 11:49:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 04 Jan 2016 19:49:29 -0000 > If the text looks good for you, please state so in the mailing list. I am fine with the text. But I have one comment about sequencing the = list below. Can we sequence the list in order of generality or = importance? See inline comment below. > Beside this main focus, the LISP WG work on the following items: >=20 > - NAT-Traversal >=20 > - Mobility >=20 > - Data-Plane Encryption >=20 > - Multicast: Support for overlay multicast by means of > replication as well as interfacing with existing > underlay multicast support. >=20 > - Models for managing the LISP protocol and deployments > that include data models, as well as allowing for > programmable management interfaces. These managament > methods should be considered for both the data-plane, > control-plane, and mapping system components >=20 > - Multi-protocol support: Specifying the required > extensions to support multi-protocol encapsulation > (e.g., L2 or NSH =E2=80=93 Network Service Headers). Rather > than developing new encapsulations the work will aim > at using existing well-established encapsulations or > emerging from other Working Grops such as NVO3 and SFC. >=20 > - Alternative Mapping System Design. By extenting LISP > with new protocols support it is also necessary to > develop the required mapping function extensions to > operate LISP map-assisted networks (which might > include Hierarchical Pull, Publish/Subscribe, or Push > models and related security extension). I will number the above as 1 - 7 and feel they should be ordered in = sequence: 6, 7, 2, 4, 3, 1, 5 Dino From nobody Mon Jan 4 14:42:40 2016 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 356481AC442 for ; Mon, 4 Jan 2016 14:42:40 -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 uvf8kjss_Pln for ; Mon, 4 Jan 2016 14:42:38 -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 6E3A91A1AA8 for ; Mon, 4 Jan 2016 14:42:38 -0800 (PST) Received: by mail-pa0-x233.google.com with SMTP id yy13so111328481pab.3 for ; Mon, 04 Jan 2016 14:42:38 -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:cc:date :content-transfer-encoding:message-id:references:to; bh=sv82E+JaC88OKI4N1/pf3JSOZ0kA5fvf6S9ydwvnGQ8=; b=OcoCnU+4LnIH5Bx9R0nGz35tlP4XvM1gRnsN9SF5n4hCuT8L7++myJqb8PamOfyWfw 6ufjKw7ynsTtUTX8A8tQTXLNHHUZU8EKCrKtfG6hBYhPHKlL/9wHrbwKiMgsR3bjItRx CxS2SgCwTDyYELo++AwGlp7H6hpKMJXJu8Ns0yBhyQuFr+BNPGFCBqgvVoBoCMFOjxjq i5vXSp0mI1KKaUp4EiBs6G0C6SdJqZ1JlJDRRCca6yzQTw6Rmc5cWrW5YBP+M9Db+JQD Evzq+udGh2LIUmgEQAoclCICoNCv4XtjT2XXSqZ1l588lAjK7HMpsMrPnviXr3b0GrW/ fjqg== X-Received: by 10.67.3.196 with SMTP id by4mr128651394pad.67.1451947358046; Mon, 04 Jan 2016 14:42:38 -0800 (PST) Received: from ?IPv6:2600:1010:b057:3db2:5c6e:fa8f:d04c:3220? ([2600:1010:b057:3db2:5c6e:fa8f:d04c:3220]) by smtp.gmail.com with ESMTPSA id d86sm123243872pfj.85.2016.01.04.14.42.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jan 2016 14:42:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (13C75) In-Reply-To: <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> Date: Mon, 4 Jan 2016 14:42:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> To: Dino Farinacci Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 04 Jan 2016 22:42:40 -0000 I agree with Dino, will pull up (1) though, it allows carriers to anchor acc= ess services in POPs where the MAO operations are based. Cloud RAN, NFV, VPN .. type services. --szb On Jan 4, 2016, at 11:49 AM, Dino Farinacci wrote: >> If the text looks good for you, please state so in the mailing list. >=20 > I am fine with the text. But I have one comment about sequencing the list b= elow. Can we sequence the list in order of generality or importance? >=20 > See inline comment below. >=20 >> Beside this main focus, the LISP WG work on the following items: >>=20 >> - NAT-Traversal >>=20 >> - Mobility >>=20 >> - Data-Plane Encryption >>=20 >> - Multicast: Support for overlay multicast by means of >> replication as well as interfacing with existing >> underlay multicast support. >>=20 >> - Models for managing the LISP protocol and deployments >> that include data models, as well as allowing for >> programmable management interfaces. These managament >> methods should be considered for both the data-plane, >> control-plane, and mapping system components >>=20 >> - Multi-protocol support: Specifying the required >> extensions to support multi-protocol encapsulation >> (e.g., L2 or NSH =E2=80=93 Network Service Headers). Rather >> than developing new encapsulations the work will aim >> at using existing well-established encapsulations or >> emerging from other Working Grops such as NVO3 and SFC. >>=20 >> - Alternative Mapping System Design. By extenting LISP >> with new protocols support it is also necessary to >> develop the required mapping function extensions to >> operate LISP map-assisted networks (which might >> include Hierarchical Pull, Publish/Subscribe, or Push >> models and related security extension). >=20 > I will number the above as 1 - 7 and feel they should be ordered in sequen= ce: >=20 > 6, 7, 2, 4, 3, 1, 5 >=20 > Dino >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jan 4 14:47:03 2016 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 B927A1ACC86 for ; Mon, 4 Jan 2016 14:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 023vuSTG2NKu for ; Mon, 4 Jan 2016 14:47:01 -0800 (PST) Received: from osiris.lip6.fr (osiris.lip6.fr [132.227.60.30]) by ietfa.amsl.com (Postfix) with ESMTP id 917861AC410 for ; Mon, 4 Jan 2016 14:47:00 -0800 (PST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.15.1/lip6) with ESMTP id u04MkwYb025928 for ; Mon, 4 Jan 2016 23:46:58 +0100 (CET) X-pt: osiris.lip6.fr Received: from [192.168.1.42] (bre75-4-78-194-65-24.fbxo.proxad.net [78.194.65.24]) (authenticated bits=0) by tibre.lip6.fr (8.15.1/8.14.7) with ESMTPSA id u04MkwpH018455 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Jan 2016 23:46:58 +0100 (MET) From: Stefano Secci Content-Type: multipart/alternative; boundary="Apple-Mail=_5B4631D2-8DAC-44D2-9129-28903DAFBFCB" Message-Id: <91600CE8-B881-4947-BEB2-E04486FBE566@lip6.fr> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Mon, 4 Jan 2016 23:46:58 +0100 References: To: lisp@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1993) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (osiris.lip6.fr [132.227.60.30]); Mon, 04 Jan 2016 23:46:58 +0100 (CET) X-Scanned-By: MIMEDefang 2.75 on 132.227.60.30 Archived-At: Subject: Re: [lisp] Update Proposed CHarter 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, 04 Jan 2016 22:47:02 -0000 --Apple-Mail=_5B4631D2-8DAC-44D2-9129-28903DAFBFCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, the text looks ok to me and fully agree with Dino's order of = preference/importance. Just a comment for current point 7 - it might be worth being more = explicit on independent mapping system interconnect / inter-domain = mapping system issues. Cheers, Stefano >> If the text looks good for you, please state so in the mailing list. >=20 > I am fine with the text. But I have one comment about sequencing the = list below. Can we sequence the list in order of generality or = importance? >=20 > See inline comment below. >=20 >> Beside this main focus, the LISP WG work on the following items: >>=20 >> - NAT-Traversal >>=20 >> - Mobility >>=20 >> - Data-Plane Encryption >>=20 >> - Multicast: Support for overlay multicast by means of >> replication as well as interfacing with existing >> underlay multicast support. >>=20 >> - Models for managing the LISP protocol and deployments >> that include data models, as well as allowing for >> programmable management interfaces. These managament >> methods should be considered for both the data-plane, >> control-plane, and mapping system components >>=20 >> - Multi-protocol support: Specifying the required >> extensions to support multi-protocol encapsulation >> (e.g., L2 or NSH ? Network Service Headers). Rather >> than developing new encapsulations the work will aim >> at using existing well-established encapsulations or >> emerging from other Working Grops such as NVO3 and SFC. >>=20 >> - Alternative Mapping System Design. By extenting LISP >> with new protocols support it is also necessary to >> develop the required mapping function extensions to >> operate LISP map-assisted networks (which might >> include Hierarchical Pull, Publish/Subscribe, or Push >> models and related security extension). >=20 > I will number the above as 1 - 7 and feel they should be ordered in = sequence: >=20 > 6, 7, 2, 4, 3, 1, 5 >=20 > Dino --=20 Stefano Secci Associate Professor Univ. Pierre and Marie Curie LIP6 - Bureau 25-26/518, BC 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 http://www-phare.lip6.fr/~secci=20 --Apple-Mail=_5B4631D2-8DAC-44D2-9129-28903DAFBFCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi WG,

the text looks ok to me = and fully agree with Dino's order of preference/importance.

Just a comment for = current point 7 - it might be worth being more explicit on independent = mapping system interconnect / inter-domain mapping system = issues.

Cheers,
Stefano

If the text looks good = for you, please state so in the mailing list.

I am fine with the text. But I = have one comment about sequencing the list below. Can we = sequence the list in order of generality or importance?

See inline comment below.

Beside this main focus, the LISP WG work on the = following items:

-       = NAT-Traversal

-       = Mobility

-       Data-Plane = Encryption

-       = Multicast: Support for overlay multicast by means of
  =     replication as well as interfacing with existing
      underlay multicast support.

-       Models for managing the = LISP protocol and deployments
      that = include data models, as well as allowing for
    =   programmable management interfaces. These managament
      methods should be considered for both = the data-plane,
      control-plane, and = mapping system components

-     =   Multi-protocol support: Specifying the required
      extensions to support multi-protocol = encapsulation
      (e.g.,   L2 or NSH = ? Network Service Headers). Rather
      = than developing new encapsulations the work will aim
  =     at using existing well-established encapsulations or
      emerging from other Working Grops such = as  NVO3 and SFC.

-     =   Alternative Mapping System Design. By extenting LISP
      with  new protocols support it is = also necessary to
      develop the = required mapping function extensions to
    =   operate LISP map-assisted  networks (which might
      include Hierarchical Pull, = Publish/Subscribe, or Push
      models and = related security extension).

I = will number the above as 1 - 7 and feel they should be ordered in = sequence:

6, 7, 2, 4, 3, 1, 5

Dino

-- 
Stefano Secci
Associate Professor
Univ. Pierre and Marie = Curie
LIP6 - Bureau 25-26/518, BC 169
4 = place Jussieu, 75005 Paris, France
Tel:  +33 (0) 1 = 4427 3678
http://www-phare.lip6.fr/~secci 

= --Apple-Mail=_5B4631D2-8DAC-44D2-9129-28903DAFBFCB-- From nobody Mon Jan 4 15:10:25 2016 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 9B2CC1ACD0C for ; Mon, 4 Jan 2016 15:10:23 -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 TEA26lz2KrQ9 for ; Mon, 4 Jan 2016 15:10:22 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363061ACD00 for ; Mon, 4 Jan 2016 15:10:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1F7C78C0EB3; Mon, 4 Jan 2016 15:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1451949022; bh=lGzn8YqguhZ3DNBe6rQzSrrSzgvd3s/YSmzK7Wc0KXE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZuEdx9x6weLbGyfSeD9l41mCvU/Q63+a6tyh3Pb54TwYZFoK2ODO1MZJl66CIdZXA 0n9g6W0XGt2xtNKxWdaowfmutrQ+8p4T/MkrqMZ2C06v9iUmzR475ksABTwnoZ0EW7 JR8h3MPpD2BmhRO/qwQ1LUTNUY3sxvi0S/LaVEWU= X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 9D42E8C0EA8; Mon, 4 Jan 2016 15:10:21 -0800 (PST) To: Sharon , Dino Farinacci References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> From: "Joel M. Halpern" Message-ID: <568AFBC2.2020103@joelhalpern.com> Date: Mon, 4 Jan 2016 18:09:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 04 Jan 2016 23:10:23 -0000 And this is why I tend to prefer an un-ordered list. But if the WG wants to try to agree on a prioritized list, go for it. Yours, Joel On 1/4/16 5:42 PM, Sharon wrote: > I agree with Dino, will pull up (1) though, it allows carriers to anchor access services in POPs where the MAO operations are based. > Cloud RAN, NFV, VPN .. type services. > > --szb > > On Jan 4, 2016, at 11:49 AM, Dino Farinacci wrote: > >>> If the text looks good for you, please state so in the mailing list. >> >> I am fine with the text. But I have one comment about sequencing the list below. Can we sequence the list in order of generality or importance? >> >> See inline comment below. >> >>> Beside this main focus, the LISP WG work on the following items: >>> >>> - NAT-Traversal >>> >>> - Mobility >>> >>> - Data-Plane Encryption >>> >>> - Multicast: Support for overlay multicast by means of >>> replication as well as interfacing with existing >>> underlay multicast support. >>> >>> - Models for managing the LISP protocol and deployments >>> that include data models, as well as allowing for >>> programmable management interfaces. These managament >>> methods should be considered for both the data-plane, >>> control-plane, and mapping system components >>> >>> - Multi-protocol support: Specifying the required >>> extensions to support multi-protocol encapsulation >>> (e.g., L2 or NSH – Network Service Headers). Rather >>> than developing new encapsulations the work will aim >>> at using existing well-established encapsulations or >>> emerging from other Working Grops such as NVO3 and SFC. >>> >>> - Alternative Mapping System Design. By extenting LISP >>> with new protocols support it is also necessary to >>> develop the required mapping function extensions to >>> operate LISP map-assisted networks (which might >>> include Hierarchical Pull, Publish/Subscribe, or Push >>> models and related security extension). >> >> I will number the above as 1 - 7 and feel they should be ordered in sequence: >> >> 6, 7, 2, 4, 3, 1, 5 >> >> Dino >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jan 4 15:30:07 2016 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 093E41ACD2E for ; Mon, 4 Jan 2016 15:30:06 -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 MCW7P0um46ZS for ; Mon, 4 Jan 2016 15:30:03 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8866D1ACD37 for ; Mon, 4 Jan 2016 15:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10343; q=dns/txt; s=iport; t=1451950203; x=1453159803; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=y9E82WfczLX+A2PpGMFZvesd3KQcIKV2dxHfcD75xr4=; b=fpnQEc4m6IwS5Ho2qH7cfz1ut0BFtOPoSfBHQIwVeTQ0JMSjn0QK1RWD KqvDKy+mqf25udryeGJ7N8n20iCu0/VNJBjmwvK816+IKn2hJhWksfhyY iWumKBl12g3BW55RUUw689EqyEo9URkl3bdXsbwfIe3wfQLCBgwVF7veD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCh/4pW/4cNJK1UCoM6Um2IWbN3A?= =?us-ascii?q?Q2BZBgBCYVtAoEeOBQBAQEBAQEBgQqENQEBBAEBASBJAgoRCxIGCQMTCwICCQM?= =?us-ascii?q?CAQIBFSIOEwYCAQEXiBQOsDqQfwEBAQcBAQEBARoEhlaEf4QsCwEBBYM1gUkFj?= =?us-ascii?q?jCIVo1RgVyERoMFhVSFWIhiIAEBQoQrHTSDToFCAQEB?= X-IronPort-AV: E=Sophos;i="5.20,522,1444694400"; d="scan'208,217";a="224335271" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jan 2016 23:30:02 +0000 Received: from [10.24.90.49] ([10.24.90.49]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u04NU1LC026010 for ; Mon, 4 Jan 2016 23:30:01 GMT To: lisp@ietf.org References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> From: Fabio Maino Message-ID: <568B0079.4080108@cisco.com> Date: Mon, 4 Jan 2016 15:30:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> Content-Type: multipart/alternative; boundary="------------030900060205060700070506" Archived-At: Subject: Re: [lisp] Update Proposed CHarter 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, 04 Jan 2016 23:30:06 -0000 This is a multi-part message in MIME format. --------------030900060205060700070506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Luigi, it looks good to me. One item that was mentioned at the last meeting was to include the work done so far on map server reliable transport. One possible way to include it is to change the very last bullet to something like: - Alternative Mapping System Design. By extending LISP with new protocols support it is also necessary to develop the required mapping function extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models and related security extensions, *or alternative transports of the LISP control protocol*). Thanks, Fabio On 1/4/16 4:44 AM, Luigi Iannone wrote: > Hi and Happy 2016 to All, > > time to restart our WG activity in this new year. ;-) > > We tried to include all comments received via mail and stated during the last meeting in Japan into an updated charter. > Changes are relatively minor, showing that the WG has almost converged to a proposal. > Yet, before pushing the new charter to the IESG for approval, we would like to have a last short iteration in the WG. > Hereafter you can find the updated text. > > If the text looks good for you, please state so in the mailing list. > > If you think something is missing or can be improved, please state so in the mailing list. > > Thanks > > Joel and Luigi > > > %%%%%%%% Updated Proposed Charter %%%%%%%%%%%%%%%%%%%%%%%% > > LISP WG has completed the first set of Experimental RFCs > describing the Locator/ID Separation Protocol (LISP). > LISP supports a routing architecture which decouples > the routing locators and identifiers, thus allowing for > efficient aggregation of the routing locator space and > providing persistent identifiers in the identifier space. > LISP requires no changes to end-systems or to routers > that do not directly participate in the LISP deployment. > LISP aims for an incrementally deployable protocol. > The scope of the LISP techology is recognized to range > from unicast and multicast overlays at Layer 2 as well > as at Layer 3, including NAT traversal, VPNs, and > supporting mobility as a general feature, independently > of wheter it is a mobile user or a migrating VM, hence > being applicable in both Data Centers and public Internet > environments. > > The LISP WG is chartered to continue work on the LISP base > protocol with the main objective to develop a standard > solution based on the completed Experimental RFCs and the > experience gained from early deployments. > > This work will include reviewing the existing set of > Experimental RFCs and doing the necessary enhancements to > support a base set of standards track RFCs. The group will > review the current set of Working Group documents to > identify potential standards-track documents and do the > necessary enhancements to support standards-track. It is > recognized that some of the work will continue on the > experimental track, though the group is encouraged to > move the documents to standards track in support of network > use, whereas the work previously was scoped to experimental > documents. > > Beside this main focus, the LISP WG work on the following items: > > - NAT-Traversal > > - Mobility > > - Data-Plane Encryption > > - Multicast: Support for overlay multicast by means of > replication as well as interfacing with existing > underlay multicast support. > > - Models for managing the LISP protocol and deployments > that include data models, as well as allowing for > programmable management interfaces. These managament > methods should be considered for both the data-plane, > control-plane, and mapping system components > > - Multi-protocol support: Specifying the required > extensions to support multi-protocol encapsulation > (e.g., L2 or NSH – Network Service Headers). Rather > than developing new encapsulations the work will aim > at using existing well-established encapsulations or > emerging from other Working Grops such as NVO3 and SFC. > > - Alternative Mapping System Design. By extenting LISP > with new protocols support it is also necessary to > develop the required mapping function extensions to > operate LISP map-assisted networks (which might > include Hierarchical Pull, Publish/Subscribe, or Push > models and related security extension). > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------030900060205060700070506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Luigi,
it looks good to me.

One item that was mentioned at the last meeting was to include the work done so far on map server reliable transport.

One possible way to include it is to change the very last bullet to something like:

- Alternative Mapping System Design. By extending LISP with  new protocols support it is also necessary to develop the required mapping function extensions to operate LISP map-assisted  networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models and related security extensions, or alternative transports of the LISP control protocol).

Thanks,
Fabio




On 1/4/16 4:44 AM, Luigi Iannone wrote:
Hi and Happy 2016 to All,

time to restart our WG activity in this new year. ;-)

We tried to include all comments received via mail and stated during the last meeting in Japan into an updated charter.
Changes are relatively minor, showing that the WG has almost converged to a proposal.
Yet, before pushing the new charter to the IESG for approval, we would like to have a last short iteration in the WG.
Hereafter you can find the updated text. 

If the text looks good for you, please state so in the mailing list.

If you think something is missing or can be improved, please state so in the mailing list.

Thanks 

Joel and Luigi


%%%%%%%% Updated Proposed Charter %%%%%%%%%%%%%%%%%%%%%%%%

LISP WG has completed the first set of Experimental RFCs 
describing the Locator/ID Separation Protocol (LISP). 
LISP supports a routing architecture which decouples 
the routing locators and identifiers, thus allowing for 
efficient aggregation of the routing locator space and 
providing persistent identifiers in the identifier space. 
LISP requires no changes to end-systems or to routers 
that do not directly participate in the LISP deployment. 
LISP aims for an incrementally deployable protocol. 
The scope of the LISP techology is recognized to range 
from unicast and multicast overlays at Layer 2 as well 
as at Layer 3, including NAT traversal, VPNs, and 
supporting mobility as a general feature, independently 
of wheter it is a mobile user or a migrating VM, hence 
being applicable in both Data Centers and public Internet 
environments.

The LISP WG is chartered to continue work on the LISP base 
protocol with the main objective to develop a standard 
solution based on the completed Experimental RFCs and the 
experience gained from early deployments.

This work will include reviewing the existing set of  
Experimental RFCs and doing the necessary enhancements to  
support a base set of standards track RFCs. The group will 
review the current set of Working Group documents to  
identify potential standards-track documents and do the 
necessary enhancements to support standards-track. It is  
recognized that some of the work will continue on the 
experimental track, though the group is encouraged to
move the documents to standards track in support of network
use, whereas the work previously was scoped to experimental
documents.

Beside this main focus, the LISP WG work on the following items:

-       NAT-Traversal

-       Mobility

-       Data-Plane Encryption

-       Multicast: Support for overlay multicast by means of
        replication as well as interfacing with existing
        underlay multicast support.

-       Models for managing the LISP protocol and deployments
        that include data models, as well as allowing for
        programmable management interfaces. These managament
        methods should be considered for both the data-plane,
        control-plane, and mapping system components

-       Multi-protocol support: Specifying the required
        extensions to support multi-protocol encapsulation
        (e.g.,   L2 or NSH – Network Service Headers). Rather
        than developing new encapsulations the work will aim
        at using existing well-established encapsulations or
        emerging from other Working Grops such as  NVO3 and SFC.

-       Alternative Mapping System Design. By extenting LISP
        with  new protocols support it is also necessary to
        develop the required mapping function extensions to
        operate LISP map-assisted  networks (which might
        include Hierarchical Pull, Publish/Subscribe, or Push
        models and related security extension).

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

--------------030900060205060700070506-- From nobody Mon Jan 4 15:49:00 2016 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 6FEBE1ACD62 for ; Mon, 4 Jan 2016 15:48:59 -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 oSZGVVN9pfcn for ; Mon, 4 Jan 2016 15:48:57 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 9B4641ACD61 for ; Mon, 4 Jan 2016 15:48:57 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 65so164628707pff.3 for ; Mon, 04 Jan 2016 15:48:57 -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=E99Dr80YYIODMSbfm4OZbb8QEv5A4ywovJ4wxY3MqFc=; b=ssEVlyiocq8A1PyUdu9V//kDxrU+mVm251oZLjWhWDyPci1aejG11qMY+cxVdQ0CIB KzsEqEFSHV8vKUUQh37fT2e8V/tWlKWd+ZtLI5kFQ0cHLijHVAtlvS+AT+MHt+vmTJgY zvGWEvjirntKL+rc1COOIW5bGQQ7BC8rKNlG1qM1Z7FcSmuYS+aITM2LBtSlIvuBMC07 ePO3MYvm/xw09jGIFNfKRf7tbk3+XojlO8vz8MDmC4IinKUtZnXK+yuAsJc+AmeLk6eY 5/uK+nF+DJjGa0s2AxOPn8Z1FwZj/CbpphszZ2Qhnx7SlmCS/5ymBrrSPtyaC/YHNaIq JlIA== X-Received: by 10.98.68.68 with SMTP id r65mr81376521pfa.108.1451951337361; Mon, 04 Jan 2016 15:48:57 -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 tm4sm128705464pab.3.2016.01.04.15.48.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jan 2016 15:48:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <568AFBC2.2020103@joelhalpern.com> Date: Mon, 4 Jan 2016 15:48:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> <568AFBC2.2020103@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 04 Jan 2016 23:48:59 -0000 I should have NOT said in =E2=80=9Corder of importance=E2=80=9D. It is = in order of more general to specific features. They are all important = and a bullet at the end is not any less important or less priority than = prior bullets. Dino > On Jan 4, 2016, at 3:09 PM, Joel M. Halpern = wrote: >=20 > And this is why I tend to prefer an un-ordered list. But if the WG = wants to try to agree on a prioritized list, go for it. >=20 > Yours, > Joel >=20 > On 1/4/16 5:42 PM, Sharon wrote: >> I agree with Dino, will pull up (1) though, it allows carriers to = anchor access services in POPs where the MAO operations are based. >> Cloud RAN, NFV, VPN .. type services. >>=20 >> --szb >>=20 >> On Jan 4, 2016, at 11:49 AM, Dino Farinacci = wrote: >>=20 >>>> If the text looks good for you, please state so in the mailing = list. >>>=20 >>> I am fine with the text. But I have one comment about sequencing the = list below. Can we sequence the list in order of generality or = importance? >>>=20 >>> See inline comment below. >>>=20 >>>> Beside this main focus, the LISP WG work on the following items: >>>>=20 >>>> - NAT-Traversal >>>>=20 >>>> - Mobility >>>>=20 >>>> - Data-Plane Encryption >>>>=20 >>>> - Multicast: Support for overlay multicast by means of >>>> replication as well as interfacing with existing >>>> underlay multicast support. >>>>=20 >>>> - Models for managing the LISP protocol and deployments >>>> that include data models, as well as allowing for >>>> programmable management interfaces. These managament >>>> methods should be considered for both the data-plane, >>>> control-plane, and mapping system components >>>>=20 >>>> - Multi-protocol support: Specifying the required >>>> extensions to support multi-protocol encapsulation >>>> (e.g., L2 or NSH =E2=80=93 Network Service Headers). Rather >>>> than developing new encapsulations the work will aim >>>> at using existing well-established encapsulations or >>>> emerging from other Working Grops such as NVO3 and SFC. >>>>=20 >>>> - Alternative Mapping System Design. By extenting LISP >>>> with new protocols support it is also necessary to >>>> develop the required mapping function extensions to >>>> operate LISP map-assisted networks (which might >>>> include Hierarchical Pull, Publish/Subscribe, or Push >>>> models and related security extension). >>>=20 >>> I will number the above as 1 - 7 and feel they should be ordered in = sequence: >>>=20 >>> 6, 7, 2, 4, 3, 1, 5 >>>=20 >>> Dino >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jan 4 17:49:09 2016 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 D290C1ACE46 for ; Mon, 4 Jan 2016 17:49:07 -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 BIURCtvhWBnD for ; Mon, 4 Jan 2016 17:49:06 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CE81ACE47 for ; Mon, 4 Jan 2016 17:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3686; q=dns/txt; s=iport; t=1451958546; x=1453168146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ltXozePUCl/Lf8V9IZhGKsnSCAhKV+CMbbDeUoWnMGE=; b=fPRi2tsZLxbOlcm8zJBlq+kuG7J2pr/4cC4KHNf4y6u/Qb6lTUmTOQRa YqBcJgMsznTvJoAuZP9JrSAY6+f93qpr2sx3zDDYz4U3d022JaiJyRjTB StO1ZMWfr+6ojN37DmSLS9bYixYDyZesdgY5DrkkgUlZh3SSYqFiNimDe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBpIItW/4YNJK1egzpSbQaIU7N3A?= =?us-ascii?q?Q2BZBgKhW0CgR44FAEBAQEBAQGBCoQ1AQEEAQEBZAcLEAIBCBgMIiEGCyUCBAE?= =?us-ascii?q?NBYgaAxIOvjoNgnQBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWhH+CT4ZtBY1zi?= =?us-ascii?q?RMBiDCDKIF4gVyERohZhViBCYdYASABAUKCFheBXXKECIEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,523,1444694400"; d="scan'208";a="224368060" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jan 2016 01:49:04 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u051n4u6000871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 01:49:04 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Jan 2016 19:49:04 -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; Mon, 4 Jan 2016 19:49:04 -0600 From: "Vina Ermagan (vermagan)" To: "Joel M. Halpern" , Sharon , "Dino Farinacci" Thread-Topic: [lisp] Update Proposed CHarter Thread-Index: AQHRRu21HHJELY4k+UCUQcVryKwMOJ7sKLMAgAAwbgCAAAejAP//ploA Date: Tue, 5 Jan 2016 01:49:04 +0000 Message-ID: References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> <568AFBC2.2020103@joelhalpern.com> In-Reply-To: <568AFBC2.2020103@joelhalpern.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.133] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <14BB5D935256434DA5CFA4F6AB76B31A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 05 Jan 2016 01:49:08 -0000 Hello Chairs, Thanks for the text. One minor comment: in addition to Fabio's suggestion, perhaps we can also include a wording that explicitly includes control plane protocol extensions needed to accommodate the new mapping functions. I have captures both additions in << >> below. - Alternative Mapping System Design. By extending LISP with new protocols support it is also necessary to develop the required mapping function << and control plane >> extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models and related security extensions, << or alternative transports of the LISP control protocol >>). Regarding the ordering of the list, I believe we should stay away from officially prioritizing the list in the charter. Therefore I think we should avoid numbering the list. I have no objection to re-arranging the list in any order as long as it does not imply prioritization. Best, Vina On 1/4/16 3:09 PM, "Joel M. Halpern" wrote: >And this is why I tend to prefer an un-ordered list. But if the WG >wants to try to agree on a prioritized list, go for it. > >Yours, >Joel > >On 1/4/16 5:42 PM, Sharon wrote: >> I agree with Dino, will pull up (1) though, it allows carriers to >>anchor access services in POPs where the MAO operations are based. >> Cloud RAN, NFV, VPN .. type services. >> >> --szb >> >> On Jan 4, 2016, at 11:49 AM, Dino Farinacci wrote: >> >>>> If the text looks good for you, please state so in the mailing list. >>> >>> I am fine with the text. But I have one comment about sequencing the >>>list below. Can we sequence the list in order of generality or >>>importance? >>> >>> See inline comment below. >>> >>>> Beside this main focus, the LISP WG work on the following items: >>>> >>>> - NAT-Traversal >>>> >>>> - Mobility >>>> >>>> - Data-Plane Encryption >>>> >>>> - Multicast: Support for overlay multicast by means of >>>> replication as well as interfacing with existing >>>> underlay multicast support. >>>> >>>> - Models for managing the LISP protocol and deployments >>>> that include data models, as well as allowing for >>>> programmable management interfaces. These managament >>>> methods should be considered for both the data-plane, >>>> control-plane, and mapping system components >>>> >>>> - Multi-protocol support: Specifying the required >>>> extensions to support multi-protocol encapsulation >>>> (e.g., L2 or NSH =AD Network Service Headers). Rather >>>> than developing new encapsulations the work will aim >>>> at using existing well-established encapsulations or >>>> emerging from other Working Grops such as NVO3 and SFC. >>>> >>>> - Alternative Mapping System Design. By extenting LISP >>>> with new protocols support it is also necessary to >>>> develop the required mapping function extensions to >>>> operate LISP map-assisted networks (which might >>>> include Hierarchical Pull, Publish/Subscribe, or Push >>>> models and related security extension). >>> >>> I will number the above as 1 - 7 and feel they should be ordered in >>>sequence: >>> >>> 6, 7, 2, 4, 3, 1, 5 >>> >>> Dino >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Jan 5 14:39:33 2016 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 4DAE51A034C for ; Tue, 5 Jan 2016 14:39:32 -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 SBeQ9R2EVlwO for ; Tue, 5 Jan 2016 14:39:30 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 1389B1A032D for ; Tue, 5 Jan 2016 14:39:30 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id f206so40481596wmf.0 for ; Tue, 05 Jan 2016 14:39:29 -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=Bm4gJS1FRa9z9bhUQ5frz8eMQWP14wmLGfI4DDGKZWg=; b=b16lLyWUiA6r7cpmUVhNHV9Oh/CpnMr9m7WVhkp6vmCJpYBpsQqHyRcyLvWnY4ixqn c3FCRid48dU/sH7KAvoVrij1aOZwZzRX4hn6nr2/r2w2wJaF43j5O3PQgqB0geN0XVTb ktg5mDtGQMy9DPbD3oEKameRLaSfL5acLgCd/LhlNpYkYOX1OTWbZ3QqfZ0sv4gIwRNT HgUTzY3SdSxAhzKSTjEIusCm17GT5S723wnaXMKYrjmeT27v/hvC0g6NEY8rxDB7jCY3 kmfi/SSkVf+v9CBnxs9CwrYVOo9uF19iiPTX05z/YZFl+/tD/OPaUBzi1VjJAQngoEdi sCLg== X-Received: by 10.28.63.200 with SMTP id m191mr6818105wma.67.1452033568670; Tue, 05 Jan 2016 14:39:28 -0800 (PST) Received: from [10.188.169.250] (ppp-seco21th2-46-193-174-136.wb.wifirst.net. [46.193.174.136]) by smtp.gmail.com with ESMTPSA id w73sm5594967wmw.21.2016.01.05.14.39.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jan 2016 14:39:27 -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, 5 Jan 2016 23:39:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FD8A875-D110-4AF6-B54B-CF91B4A4A48E@gmail.com> References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> <568AFBC2.2020103@joelhalpern.com> To: "Vina Ermagan (vermagan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 05 Jan 2016 22:39:32 -0000 Dear chairs, I support the new chartes with the changes proposed by Fabio and Vina. As Joel and Vina, I would prefer not to order the different points as = such prioritisation would be highly subjective. Cheers, Damien Saucez=20 On 05 Jan 2016, at 02:49, Vina Ermagan (vermagan) = wrote: > Hello Chairs, >=20 > Thanks for the text. One minor comment: in addition to Fabio's = suggestion, > perhaps we can also include a wording that explicitly includes control > plane protocol extensions needed to accommodate the new mapping = functions. > I have captures both additions in << >> below. >=20 > - Alternative Mapping System Design. By extending LISP with new = protocols > support it is also necessary to develop the required mapping function = << > and control plane >> extensions to operate LISP map-assisted networks > (which might include Hierarchical Pull, Publish/Subscribe, or Push = models > and related security extensions, << or alternative transports of the = LISP > control protocol >>). >=20 > Regarding the ordering of the list, I believe we should stay away from > officially prioritizing the list in the charter. Therefore I think we > should avoid numbering the list. I have no objection to re-arranging = the > list in any order as long as it does not imply prioritization. >=20 > Best, > Vina >=20 > On 1/4/16 3:09 PM, "Joel M. Halpern" wrote: >=20 >> And this is why I tend to prefer an un-ordered list. But if the WG >> wants to try to agree on a prioritized list, go for it. >>=20 >> Yours, >> Joel >>=20 >> On 1/4/16 5:42 PM, Sharon wrote: >>> I agree with Dino, will pull up (1) though, it allows carriers to >>> anchor access services in POPs where the MAO operations are based. >>> Cloud RAN, NFV, VPN .. type services. >>>=20 >>> --szb >>>=20 >>> On Jan 4, 2016, at 11:49 AM, Dino Farinacci = wrote: >>>=20 >>>>> If the text looks good for you, please state so in the mailing = list. >>>>=20 >>>> I am fine with the text. But I have one comment about sequencing = the >>>> list below. Can we sequence the list in order of generality or >>>> importance? >>>>=20 >>>> See inline comment below. >>>>=20 >>>>> Beside this main focus, the LISP WG work on the following items: >>>>>=20 >>>>> - NAT-Traversal >>>>>=20 >>>>> - Mobility >>>>>=20 >>>>> - Data-Plane Encryption >>>>>=20 >>>>> - Multicast: Support for overlay multicast by means of >>>>> replication as well as interfacing with existing >>>>> underlay multicast support. >>>>>=20 >>>>> - Models for managing the LISP protocol and deployments >>>>> that include data models, as well as allowing for >>>>> programmable management interfaces. These managament >>>>> methods should be considered for both the data-plane, >>>>> control-plane, and mapping system components >>>>>=20 >>>>> - Multi-protocol support: Specifying the required >>>>> extensions to support multi-protocol encapsulation >>>>> (e.g., L2 or NSH =AD Network Service Headers). Rather >>>>> than developing new encapsulations the work will aim >>>>> at using existing well-established encapsulations or >>>>> emerging from other Working Grops such as NVO3 and SFC. >>>>>=20 >>>>> - Alternative Mapping System Design. By extenting LISP >>>>> with new protocols support it is also necessary to >>>>> develop the required mapping function extensions to >>>>> operate LISP map-assisted networks (which might >>>>> include Hierarchical Pull, Publish/Subscribe, or Push >>>>> models and related security extension). >>>>=20 >>>> I will number the above as 1 - 7 and feel they should be ordered in >>>> sequence: >>>>=20 >>>> 6, 7, 2, 4, 3, 1, 5 >>>>=20 >>>> Dino >>>>=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 Wed Jan 6 06:21:29 2016 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 4D3331B2BFC for ; Wed, 6 Jan 2016 06:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 B83rFjrJiSNq for ; Wed, 6 Jan 2016 06:21:26 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C46B31B2BF9 for ; Wed, 6 Jan 2016 06:21:25 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id f206so77643241wmf.0 for ; Wed, 06 Jan 2016 06:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EO+qFIaDOJA0B2si0Yqu5+8hTE8Ny4/067DTIiffty0=; b=0lUOSbffcucPDCNCDj0K9ZN27iDWj2SITzvDaRA6rZ+9ZHxH3ydqMK6raDMSukIFSy wyS5WNXc683ksMUMUYV2wyLHNB0Kt55m6mZkF/HAD57IwCFE7nuyuqFYizIOM9YLmQVu 1ZFb6oE1IvAmqQW9z0gAjLWBJpVEqgpBrYYi7m9LLP82Z9YmwfEJ9m+OjCS6x0yubCf6 9xxJKy3Jo38RHVa38IL0CgBYhJSYyabq7CjrNcriyd5M+P1GwMkBmOtM4QBeZwGZV6w6 JToNstEx7CT7Hr/peQjfE4XllpjKf/oVZWswuRIarlj8+YSYwXEnz81wifIih0wcymGp N/Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=EO+qFIaDOJA0B2si0Yqu5+8hTE8Ny4/067DTIiffty0=; b=daWe1wEr/4yrQRpAc9P4eI8+4Dj5kXKnjPKczXJBQnY8kldaCc4FY4KtyptO3JC1JP 9uHmnRNZCaxVWwjs5GTa7pZdlDFyXdvFJdHKYpr5oXV7bM4zBEszM5IDG42auLn0sB3R NJNEtD7wBP+QchRrqQ4IjRpuS/0khF4GnOyFWdnUpWCKNeiAXgl12H7howRvyYmAJWSb e8xwmKX6w5WVTRUNgvcCZT6dyQQYylP5y5gfWYySITVlfw231yjf1yQces0qYNG8t4TM rmVOFTWaWkbpWZBrvUdHINldLnvJWpDnPARlg+BYMNx0AcK1kQhIl5/tsrnAe0RbnHm8 DjOA== X-Gm-Message-State: ALoCoQnW6y3Q0AUhKK0y2EMsz5TSuxfpStIFDt1Lu0YiZ0ihB7itu1/6e1b+zD8f2fKWMf5vPF2LSCwgbj0o8Va1XGlZSrkAPg== X-Received: by 10.194.86.166 with SMTP id q6mr85091192wjz.69.1452090084263; Wed, 06 Jan 2016 06:21:24 -0800 (PST) Received: from [10.9.1.109] (napsach022.hosting-cea.net. [192.54.209.59]) by smtp.gmail.com with ESMTPSA id g187sm8957547wmf.8.2016.01.06.06.21.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 06:21:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <9FD8A875-D110-4AF6-B54B-CF91B4A4A48E@gmail.com> Date: Wed, 6 Jan 2016 15:21:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05CD26A6-1896-4847-A987-5130F92770E3@gigix.net> References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> <568AFBC2.2020103@joelhalpern.com> <9FD8A875-D110-4AF6-B54B-CF91B4A4A48E@gmail.com> To: Damien Saucez X-Mailer: Apple Mail (2.3112) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 06 Jan 2016 14:21:28 -0000 HI All, We can certainly re-order the bullets following Dino=E2=80=99s = suggestion.=20 I would not put any text about priority and/or importance, just because = any person working on a specific bullet will obviously think that = his/her work is the most important. ;-) Does it sound OK for the WG? Ciao L. > On 05 Jan 2016, at 23:39, Damien Saucez = wrote: >=20 > Dear chairs, >=20 > I support the new chartes with the changes proposed by Fabio and Vina. >=20 > As Joel and Vina, I would prefer not to order the different points as = such > prioritisation would be highly subjective. >=20 > Cheers, >=20 > Damien Saucez=20 >=20 > On 05 Jan 2016, at 02:49, Vina Ermagan (vermagan) = wrote: >=20 >> Hello Chairs, >>=20 >> Thanks for the text. One minor comment: in addition to Fabio's = suggestion, >> perhaps we can also include a wording that explicitly includes = control >> plane protocol extensions needed to accommodate the new mapping = functions. >> I have captures both additions in << >> below. >>=20 >> - Alternative Mapping System Design. By extending LISP with new = protocols >> support it is also necessary to develop the required mapping function = << >> and control plane >> extensions to operate LISP map-assisted = networks >> (which might include Hierarchical Pull, Publish/Subscribe, or Push = models >> and related security extensions, << or alternative transports of the = LISP >> control protocol >>). >>=20 >> Regarding the ordering of the list, I believe we should stay away = from >> officially prioritizing the list in the charter. Therefore I think we >> should avoid numbering the list. I have no objection to re-arranging = the >> list in any order as long as it does not imply prioritization. >>=20 >> Best, >> Vina >>=20 >> On 1/4/16 3:09 PM, "Joel M. Halpern" wrote: >>=20 >>> And this is why I tend to prefer an un-ordered list. But if the WG >>> wants to try to agree on a prioritized list, go for it. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/4/16 5:42 PM, Sharon wrote: >>>> I agree with Dino, will pull up (1) though, it allows carriers to >>>> anchor access services in POPs where the MAO operations are based. >>>> Cloud RAN, NFV, VPN .. type services. >>>>=20 >>>> --szb >>>>=20 >>>> On Jan 4, 2016, at 11:49 AM, Dino Farinacci = wrote: >>>>=20 >>>>>> If the text looks good for you, please state so in the mailing = list. >>>>>=20 >>>>> I am fine with the text. But I have one comment about sequencing = the >>>>> list below. Can we sequence the list in order of generality or >>>>> importance? >>>>>=20 >>>>> See inline comment below. >>>>>=20 >>>>>> Beside this main focus, the LISP WG work on the following items: >>>>>>=20 >>>>>> - NAT-Traversal >>>>>>=20 >>>>>> - Mobility >>>>>>=20 >>>>>> - Data-Plane Encryption >>>>>>=20 >>>>>> - Multicast: Support for overlay multicast by means of >>>>>> replication as well as interfacing with existing >>>>>> underlay multicast support. >>>>>>=20 >>>>>> - Models for managing the LISP protocol and deployments >>>>>> that include data models, as well as allowing for >>>>>> programmable management interfaces. These managament >>>>>> methods should be considered for both the data-plane, >>>>>> control-plane, and mapping system components >>>>>>=20 >>>>>> - Multi-protocol support: Specifying the required >>>>>> extensions to support multi-protocol encapsulation >>>>>> (e.g., L2 or NSH =C2=AD Network Service Headers). Rather >>>>>> than developing new encapsulations the work will aim >>>>>> at using existing well-established encapsulations or >>>>>> emerging from other Working Grops such as NVO3 and SFC. >>>>>>=20 >>>>>> - Alternative Mapping System Design. By extenting LISP >>>>>> with new protocols support it is also necessary to >>>>>> develop the required mapping function extensions to >>>>>> operate LISP map-assisted networks (which might >>>>>> include Hierarchical Pull, Publish/Subscribe, or Push >>>>>> models and related security extension). >>>>>=20 >>>>> I will number the above as 1 - 7 and feel they should be ordered = in >>>>> sequence: >>>>>=20 >>>>> 6, 7, 2, 4, 3, 1, 5 >>>>>=20 >>>>> Dino >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jan 6 06:27:10 2016 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 CB67C1B2C03 for ; Wed, 6 Jan 2016 06:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 MzLaXwrn7Uon for ; Wed, 6 Jan 2016 06:27:07 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 957E71A7018 for ; Wed, 6 Jan 2016 06:27:07 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id b14so77850476wmb.1 for ; Wed, 06 Jan 2016 06:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=71j3hKnnDg9SP0Un7XyzFBBv0SXbJMEmexxjXh9xvVk=; b=EhC8ZygMMFQw6fRQsZHDuiyPvIdGbpSEy2hJdahQbMa/UhESAxeavHWWNLTflzjaEt w4lP/QD15qXwWw2QcCQq0Vnv6Ghc84KNDxpq3xDmD/b/Yz53TrY7HP55518P5nreYu9W TGLFdncJIcla7bHLGGNb9UQG305rwx1LPJTNe48F6AqiZbPreLtoqQKnAlrbYGK9RFAN aJ/EqUqarVPuP9brN3s82wUYG6K2i+aHWmdf1PqyROUFlROrxk4nCJyLQPb1xfXyh1iN IcrTdiwyumQlLlkvy4xKPVNibrsHpHFc78uuwgyx42QxTLt//6foqC46LU/OU5NHk9BQ IkDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=71j3hKnnDg9SP0Un7XyzFBBv0SXbJMEmexxjXh9xvVk=; b=bBvK9m/ixg9kCmzAqLZqszNOOvKZ7EaYOzCQVF5QPbxeqDuzriXLMa12t92lst1LO5 SUBV5evhUzKm9K2Ch1xiMmZJxDH0vZxGM/bfJVc7xJzDupaKstsNFs/2/dOPGhzusTc+ 4Tkqq77VoobuAC3JarJ7qcUu/greCKZR13qlxiK7jLFSuX8fVyp1CdJPAnYaurVwxVha 16/nFvKlazn6odFjTGKpE8QEEF41YvCCthy6U7/evQJaudAtx60exNtZ0Xpv6EDabfgy V7+tkKeoGUIvz14HtxkiYOlIJJ29gpYTDcxhyQ0pbTCBkkfzLxK3ya7AnuBblhrfFcBJ q38A== X-Gm-Message-State: ALoCoQnd8uVgmCQlXNSZ5zl2ruvAKXQ1UxHxHSexqns+ln/nSsQ1JE9mUd02WPgQNDppjY1EtTwjbdJq46IDlt3+ZXHoLUxnHA== X-Received: by 10.194.9.42 with SMTP id w10mr69106489wja.159.1452090426099; Wed, 06 Jan 2016 06:27:06 -0800 (PST) Received: from [10.9.1.109] (napsach022.hosting-cea.net. [192.54.209.59]) by smtp.gmail.com with ESMTPSA id kb5sm96105699wjc.20.2016.01.06.06.27.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 06:27:05 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: Date: Wed, 6 Jan 2016 15:27:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <8EB52655-5FF5-44DE-A286-D79E4BB423B2@gmail.com> <568AFBC2.2020103@joelhalpern.com> To: "Vina Ermagan (vermagan)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 06 Jan 2016 14:27:10 -0000 Thanks Vina, Fabio, I do not see any objection in adding the suggested text. Ciao L. > On 05 Jan 2016, at 02:49, Vina Ermagan (vermagan) = wrote: >=20 > Hello Chairs, >=20 > Thanks for the text. One minor comment: in addition to Fabio's = suggestion, > perhaps we can also include a wording that explicitly includes control > plane protocol extensions needed to accommodate the new mapping = functions. > I have captures both additions in << >> below. >=20 > - Alternative Mapping System Design. By extending LISP with new = protocols > support it is also necessary to develop the required mapping function = << > and control plane >> extensions to operate LISP map-assisted networks > (which might include Hierarchical Pull, Publish/Subscribe, or Push = models > and related security extensions, << or alternative transports of the = LISP > control protocol >>). >=20 > Regarding the ordering of the list, I believe we should stay away from > officially prioritizing the list in the charter. Therefore I think we > should avoid numbering the list. I have no objection to re-arranging = the > list in any order as long as it does not imply prioritization. >=20 > Best, > Vina >=20 > On 1/4/16 3:09 PM, "Joel M. Halpern" wrote: >=20 >> And this is why I tend to prefer an un-ordered list. But if the WG >> wants to try to agree on a prioritized list, go for it. >>=20 >> Yours, >> Joel >>=20 >> On 1/4/16 5:42 PM, Sharon wrote: >>> I agree with Dino, will pull up (1) though, it allows carriers to >>> anchor access services in POPs where the MAO operations are based. >>> Cloud RAN, NFV, VPN .. type services. >>>=20 >>> --szb >>>=20 >>> On Jan 4, 2016, at 11:49 AM, Dino Farinacci = wrote: >>>=20 >>>>> If the text looks good for you, please state so in the mailing = list. >>>>=20 >>>> I am fine with the text. But I have one comment about sequencing = the >>>> list below. Can we sequence the list in order of generality or >>>> importance? >>>>=20 >>>> See inline comment below. >>>>=20 >>>>> Beside this main focus, the LISP WG work on the following items: >>>>>=20 >>>>> - NAT-Traversal >>>>>=20 >>>>> - Mobility >>>>>=20 >>>>> - Data-Plane Encryption >>>>>=20 >>>>> - Multicast: Support for overlay multicast by means of >>>>> replication as well as interfacing with existing >>>>> underlay multicast support. >>>>>=20 >>>>> - Models for managing the LISP protocol and deployments >>>>> that include data models, as well as allowing for >>>>> programmable management interfaces. These managament >>>>> methods should be considered for both the data-plane, >>>>> control-plane, and mapping system components >>>>>=20 >>>>> - Multi-protocol support: Specifying the required >>>>> extensions to support multi-protocol encapsulation >>>>> (e.g., L2 or NSH =AD Network Service Headers). Rather >>>>> than developing new encapsulations the work will aim >>>>> at using existing well-established encapsulations or >>>>> emerging from other Working Grops such as NVO3 and SFC. >>>>>=20 >>>>> - Alternative Mapping System Design. By extenting LISP >>>>> with new protocols support it is also necessary to >>>>> develop the required mapping function extensions to >>>>> operate LISP map-assisted networks (which might >>>>> include Hierarchical Pull, Publish/Subscribe, or Push >>>>> models and related security extension). >>>>=20 >>>> I will number the above as 1 - 7 and feel they should be ordered in >>>> sequence: >>>>=20 >>>> 6, 7, 2, 4, 3, 1, 5 >>>>=20 >>>> Dino >>>>=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 Wed Jan 6 06:42:26 2016 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 730B21B2C2E for ; Wed, 6 Jan 2016 06:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 sCk77HtCfbdj for ; Wed, 6 Jan 2016 06:42:23 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA56C1A7035 for ; Wed, 6 Jan 2016 06:42:22 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f206so78556184wmf.0 for ; Wed, 06 Jan 2016 06:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q5tJDIoOFomeoqkck5B4RnWK/socbfKgI8YViIR4Px4=; b=Qf4J8TgQwdtwx5ACZdkTF27dhyvUu/wsxz0dKdkzP6lqskAIk05DhC4cg9QzzGujn1 4MEjMSo/BaNOxeh+lPTOc2awhPTT00TZgW3G2jwdIMpE/FSl+husQCd+lWURcl9AdrYq 3wtumkUuygoLB3FfHbq+SpDlIDYrPWGfgoQ/wkl+EZiljR822/O4Ty5SzOgo0NUy25iX eLZ/qD48ZD1Ioww8ib5SnGwzeXb54Vi4nqk50A6unS9CUI9kxkOWNz10z/hKb55eXSh7 0im1p9T3DY6HIq6vu9u80U0bERQynTdD2C92mfpUWyTfPGQwCdIAE81GjOXRAm3eD2m5 7lVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Q5tJDIoOFomeoqkck5B4RnWK/socbfKgI8YViIR4Px4=; b=IaKkAkB2PbjnQAevTGtxL/phM2STL6qoLUR5awjEpVUydUknn4Xuozwxm5fEfv/BEV GhmnUUH1jaSwBDBHyn6c8c0ACAreOQfAdGhAG4EPEbmzmh6U9lvBay2Jk5WQiRBG2v55 CioXovkDvSfA+cC2Kg/1HIQAJ4MkTBsC1jUPmaxFcCt0PbfJm9r4Od0QA9ZZ1KDqJ2Pz JJN8T0XmeuOD3R5TU0/V4+ogkVcgKn3zbZ4yluUaHqgThoiKNDLyXw2URKlQQp2rQkbi BqXMyXfPvc6RocjMkQKfYQcV9HFsfLwU9R5K1rluHZmpLtqc3LNSGnwaIgogpzdIT9Fu SSvQ== X-Gm-Message-State: ALoCoQmgTbxet+JCAFXMxk5S3eocALszB+DmWTgN5dsAcGZ5mog7l4AyNeMw0eX54Ag4LQoqdBeHE8kZUjl2MEVYoWS+8WR1UA== X-Received: by 10.28.54.65 with SMTP id d62mr10208543wma.35.1452091341237; Wed, 06 Jan 2016 06:42:21 -0800 (PST) Received: from [10.9.1.109] (napsach022.hosting-cea.net. [192.54.209.59]) by smtp.gmail.com with ESMTPSA id r10sm71971637wjz.24.2016.01.06.06.42.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 06:42:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> Date: Wed, 6 Jan 2016 15:42:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> To: LISP mailing list list X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct Subject: Re: [lisp] Update Proposed CHarter 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, 06 Jan 2016 14:42:24 -0000 Hi All, Hereafter a new version of the charter with the comments received so = far. Please send more feedback. Would be good if we can send the charter to = our AD by next week. ciao L. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The LISP WG has completed the first set of Experimental RFCs describing = the Locator/ID Separation Protocol (LISP). LISP supports a routing = architecture which decouples the routing locators and identifiers, thus = allowing for efficient aggregation of the routing locator space and = providing persistent identifiers in the identifier space. LISP requires = no changes to end-systems or to routers that do not directly participate = in the LISP deployment. LISP aims for an incrementally deployable = protocol. The scope of the LISP techology is recognized to range from = unicast and multicast overlays at Layer 2 as well as at Layer 3, = including NAT traversal, VPNs, and supporting mobility as a general = feature, independently of wheter it is a mobile user or a migrating VM, = hence being applicable in both Data Centers and public Internet = environments. The LISP WG is chartered to continue work on the LISP base protocol with = the main objective to develop a standard solution based on the completed = Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs = and doing the necessary enhancements to support a base set of standards = track RFCs. The group will review the current set of Working Group = documents to identify potential standards-track documents and do the = necessary enhancements to support standards-track. It is recognized that = some of the work will continue on the experimental track, though the = group is encouraged to move the documents to standards track in support = of network use, whereas the work previously was scoped to experimental = documents. Beside this main focus, the LISP WG work on the following items: =C2=B7 Multi-protocol support: Specifying the required extensions = to support multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service Headers). Rather than developing new encapsulations the = work will aim at using existing well-established encapsulations or = emerging from other Working Grops such as NVO3 and SFC. =20 =C2=B7 Alternative Mapping System Design. By extenting LISP with = new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independednt mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). =C2=B7 Mobility =C2=B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. =C2=B7 Data-Plane Encryption =C2=B7 NAT-Traversal =C2=B7 Models for managing the LISP protocol and deployments that = include data models, as well as allowing for programmable management = interfaces. These managament methods should be considered for both the = data-plane, control-plane, and mapping system components. =20 From nobody Wed Jan 6 12:44:10 2016 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 9A1C71A0389 for ; Wed, 6 Jan 2016 12:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkAGNfwPYKy9 for ; Wed, 6 Jan 2016 12:44:07 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEF31A00E7 for ; Wed, 6 Jan 2016 12:44:07 -0800 (PST) Received: by mail-pa0-x234.google.com with SMTP id cy9so239553717pac.0 for ; Wed, 06 Jan 2016 12:44:07 -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=NuqG7mkioLASdC9HDeJxP8SUCPO+hOprpiLjEm5ekSA=; b=Hg0/yBqieUnf0+uaBKGJ8ek03IAdIaGllAL/MYpUentYy/AfEqJhXmyuMxfAcc4RSv LG8udsLN9BZGbP7KeueV00BF1JDQ8floq9nBlo0CvKZ10ejXMD71tUQ2nWz3ayJgabjY 2W3FMZTwuojTk8B+L7bqgCOi6UdFa4Z2kBBXZqmnD2seFqlWZCAqMY+htRghIMnrI5ML XjcPIVtyoJkfhlYyKcC3iJJ2C6idbIcb9GNcgMBG/U3fhQjKK7sVYogCQyCxbrvM8k2a pCWnxNORVgJ3/+KjRaZ8frB5lOd5JRbQapliND13nySQpq/2qxtVkBHkpBjA26dot+UB YZvQ== X-Received: by 10.66.158.193 with SMTP id ww1mr143984880pab.21.1452113047512; Wed, 06 Jan 2016 12:44:07 -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 sm8sm142871977pac.43.2016.01.06.12.44.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 12:44:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> Date: Wed, 6 Jan 2016 12:44:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 06 Jan 2016 20:44:09 -0000 This version looks good to me. Dino > On Jan 6, 2016, at 6:42 AM, Luigi Iannone wrote: >=20 > Hi All, >=20 > Hereafter a new version of the charter with the comments received so = far. >=20 > Please send more feedback. Would be good if we can send the charter to = our AD by next week. >=20 > ciao >=20 > L. >=20 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >=20 >=20 > The LISP WG has completed the first set of Experimental RFCs = describing the Locator/ID Separation Protocol (LISP). LISP supports a = routing architecture which decouples the routing locators and = identifiers, thus allowing for efficient aggregation of the routing = locator space and providing persistent identifiers in the identifier = space. LISP requires no changes to end-systems or to routers that do not = directly participate in the LISP deployment. LISP aims for an = incrementally deployable protocol. The scope of the LISP techology is = recognized to range from unicast and multicast overlays at Layer 2 as = well as at Layer 3, including NAT traversal, VPNs, and supporting = mobility as a general feature, independently of wheter it is a mobile = user or a migrating VM, hence being applicable in both Data Centers and = public Internet environments. >=20 >=20 > The LISP WG is chartered to continue work on the LISP base protocol = with the main objective to develop a standard solution based on the = completed Experimental RFCs and the experience gained from early = deployments. >=20 > This work will include reviewing the existing set of Experimental RFCs = and doing the necessary enhancements to support a base set of standards = track RFCs. The group will review the current set of Working Group = documents to identify potential standards-track documents and do the = necessary enhancements to support standards-track. It is recognized that = some of the work will continue on the experimental track, though the = group is encouraged to move the documents to standards track in support = of network use, whereas the work previously was scoped to experimental = documents. >=20 > Beside this main focus, the LISP WG work on the following items: >=20 > =C2=B7 Multi-protocol support: Specifying the required = extensions to support multi-protocol encapsulation (e.g., L2 or NSH = =E2=80=93 Network Service Headers). Rather than developing new = encapsulations the work will aim at using existing well-established = encapsulations or emerging from other Working Grops such as NVO3 and = SFC. =20 >=20 > =C2=B7 Alternative Mapping System Design. By extenting LISP with = new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independednt mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). >=20 > =C2=B7 Mobility >=20 > =C2=B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. >=20 > =C2=B7 Data-Plane Encryption >=20 > =C2=B7 NAT-Traversal >=20 > =C2=B7 Models for managing the LISP protocol and deployments = that include data models, as well as allowing for programmable = management interfaces. These managament methods should be considered for = both the data-plane, control-plane, and mapping system components. >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jan 6 12:46:18 2016 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 E32951A03ED for ; Wed, 6 Jan 2016 12:46:16 -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 488JEczoW83k for ; Wed, 6 Jan 2016 12:46:15 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346EE1A03A9 for ; Wed, 6 Jan 2016 12:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3582; q=dns/txt; s=iport; t=1452113175; x=1453322775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dNEEe222H4NDr1ja0NDeXm8+3n3AB26AUe/p67GGfGk=; b=TzgPuIY4pWRDKpQvlNpNvgvlH//4BUbZ8dB4kbjY1Uit0Q9jQcANbyu7 5eCsSoXmSAj+glFr7loT0pkJSnQbaHexZNcOZUzYIy3p/hIblnw9Gu7UR gWHpwvsK8JjAmCRqtFlijMAURSxHzIThjumT5JWHcXQBTJVYF0GRiCE2b A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgBffI1W/5FdJa1UCoM6Um0GiFOzX?= =?us-ascii?q?AENgWQYCoVtAoEmOBQBAQEBAQEBgQqENQEBBAEBAWkCCxACAQgOBBIiJwsXDgI?= =?us-ascii?q?EAQ0FG4gUDsF7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVoN7gQSELCmEZwWNc?= =?us-ascii?q?4kXAY1UgVyEQ4hbhV6IaAEgAQFChApyhFmBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="scan'208";a="64634236" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 20:46:14 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u06KkEIb009958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 20:46:14 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 14:46:13 -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; Wed, 6 Jan 2016 14:46:13 -0600 From: "Vina Ermagan (vermagan)" To: Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] Update Proposed CHarter Thread-Index: AQHRRu21HHJELY4k+UCUQcVryKwMOJ7u96aA///fhIA= Date: Wed, 6 Jan 2016 20:46:13 +0000 Message-ID: References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> In-Reply-To: <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> 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.133] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <43AE35A920735D4C89A450C95EA01635@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct Subject: Re: [lisp] Update Proposed CHarter 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, 06 Jan 2016 20:46:17 -0000 Thanks Luigi, this version looks great. Best, Vina On 1/6/16 6:42 AM, "Luigi Iannone" wrote: >Hi All, > >Hereafter a new version of the charter with the comments received so far. > >Please send more feedback. Would be good if we can send the charter to >our AD by next week. > >ciao > >L. > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > >The LISP WG has completed the first set of Experimental RFCs describing >the Locator/ID Separation Protocol (LISP). LISP supports a routing >architecture which decouples the routing locators and identifiers, thus >allowing for efficient aggregation of the routing locator space and >providing persistent identifiers in the identifier space. LISP requires >no changes to end-systems or to routers that do not directly participate >in the LISP deployment. LISP aims for an incrementally deployable >protocol. The scope of the LISP techology is recognized to range from >unicast and multicast overlays at Layer 2 as well as at Layer 3, >including NAT traversal, VPNs, and supporting mobility as a general >feature, independently of wheter it is a mobile user or a migrating VM, >hence being applicable in both Data Centers and public Internet >environments. > > >The LISP WG is chartered to continue work on the LISP base protocol with >the main objective to develop a standard solution based on the completed >Experimental RFCs and the experience gained from early deployments. > >This work will include reviewing the existing set of Experimental RFCs >and doing the necessary enhancements to support a base set of standards >track RFCs. The group will review the current set of Working Group >documents to identify potential standards-track documents and do the >necessary enhancements to support standards-track. It is recognized that >some of the work will continue on the experimental track, though the >group is encouraged to move the documents to standards track in support >of network use, whereas the work previously was scoped to experimental >documents. > >Beside this main focus, the LISP WG work on the following items: > >=B7 Multi-protocol support: Specifying the required extensions to >support multi-protocol encapsulation (e.g., L2 or NSH =AD Network Servic= e >Headers). Rather than developing new encapsulations the work will aim at >using existing well-established encapsulations or emerging from other >Working Grops such as NVO3 and SFC. > >=B7 Alternative Mapping System Design. By extenting LISP with new >protocols support it is also necessary to develop the required mapping >function and control plane extensions to operate LISP map-assisted >networks (which might include Hierarchical Pull, Publish/Subscribe, or >Push models, independednt mapping systems interconnection, security >extensions, or alternative transports of the LISP control protocol). > >=B7 Mobility > >=B7 Multicast: Support for overlay multicast by means of replication >as well as interfacing with existing underlay multicast support. > >=B7 Data-Plane Encryption > >=B7 NAT-Traversal > >=B7 Models for managing the LISP protocol and deployments that >include data models, as well as allowing for programmable management >interfaces. These managament methods should be considered for both the >data-plane, control-plane, and mapping system components. > >=20 > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jan 6 13:39:52 2016 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 1AF101A1A6D for ; Wed, 6 Jan 2016 13:39:51 -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 zwZ_PCooyYxi for ; Wed, 6 Jan 2016 13:39:49 -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 5E85A1A1A6A for ; Wed, 6 Jan 2016 13:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3485; q=dns/txt; s=iport; t=1452116389; x=1453325989; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=PgEtO8QSdrVOwaFy0X8OJ7VDYwzlm5JVYO8UA2M/4FY=; b=DvceyEGhCE2bgDbiBgY30277OyPWJGntY+uKTRWldlHeCzbbc6l2aFhe e7lo1cM6okWAMdjmNx72c15lGtVNvTXFD1yOHUnkLvs8CzVbPNbXqXahC UYFUwXZCjAYWJPTwb2yQuXPgDEbJSQfB36dV4Ow6MezLupoQttPnLnT+m Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBViI1W/49dJa1UCoM6Um2IWbNaA?= =?us-ascii?q?Q2BZBgKhW0CgSY4FAEBAQEBAQGBCoQ1AQEEAQEBIA8BBTQCChELEgYCAgUDEws?= =?us-ascii?q?CAgkDAgECARUiDhMGAgEBF4gUDrEdkGMBAQEBBgEBAQEBGgSBAYVVhH+ELINHg?= =?us-ascii?q?UkFjjCEWoQAjVWBXIRDgweFVIVeiGkgAQFChCsdNIVhAQEB?= X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="scan'208";a="223403161" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 21:39:48 +0000 Received: from [10.24.42.44] ([10.24.42.44]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u06LdlIY025705 for ; Wed, 6 Jan 2016 21:39:48 GMT To: lisp@ietf.org References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> From: Fabio Maino Message-ID: <568D89A4.1020507@cisco.com> Date: Wed, 6 Jan 2016 13:39:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Update Proposed CHarter 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, 06 Jan 2016 21:39:51 -0000 Looks good Luigi. Thanks, Fabio On 1/6/16 6:42 AM, Luigi Iannone wrote: > Hi All, > > Hereafter a new version of the charter with the comments received so far. > > Please send more feedback. Would be good if we can send the charter to our AD by next week. > > ciao > > L. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The scope of the LISP techology is recognized to range from unicast and multicast overlays at Layer 2 as well as at Layer 3, including NAT traversal, VPNs, and supporting mobility as a general feature, independently of wheter it is a mobile user or a migrating VM, hence being applicable in both Data Centers and public Internet environments. > > > The LISP WG is chartered to continue work on the LISP base protocol with the main objective to develop a standard solution based on the completed Experimental RFCs and the experience gained from early deployments. > > This work will include reviewing the existing set of Experimental RFCs and doing the necessary enhancements to support a base set of standards track RFCs. The group will review the current set of Working Group documents to identify potential standards-track documents and do the necessary enhancements to support standards-track. It is recognized that some of the work will continue on the experimental track, though the group is encouraged to move the documents to standards track in support of network use, whereas the work previously was scoped to experimental documents. > > Beside this main focus, the LISP WG work on the following items: > > · Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH – Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Grops such as NVO3 and SFC. > > · Alternative Mapping System Design. By extenting LISP with new protocols support it is also necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models, independednt mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol). > > · Mobility > > · Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. > > · Data-Plane Encryption > > · NAT-Traversal > > · Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These managament methods should be considered for both the data-plane, control-plane, and mapping system components. > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sat Jan 9 14:04:57 2016 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 30FEA1A9082 for ; Sat, 9 Jan 2016 14:04:56 -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 b-uzNGz-Hwky for ; Sat, 9 Jan 2016 14:04:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4A31A9083 for ; Sat, 9 Jan 2016 14:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1452377094; x=1453586694; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Dnx+9MMZsSfWZCBBXn/woU3TK9jj2dTgBR75pvMIlLY=; b=W9e5sR+bhLMQI0zXXCkR8bYXMkS4SVx5+Xxnxhe1JSYuRYDofgDzwt37 OFZfJmKTLSHzwk4q1D/+m/HkROLc6mYJhDpvmd++Lxpq+AQtMOGAOU6Mq 1A5bJ3TvKtUWSSYaVHFNhezN2hiu03HcWk6CiZcXmNQuOkbitxiwyWU/N 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgBig5FW/5FdJa1UCoM6Um0GiFOzT?= =?us-ascii?q?wENgWYYCoVtAoEXOBQBAQEBAQEBgQqENQEBAwEBAQFpAgsFCwIBCA4EEiInCxc?= =?us-ascii?q?OAgQOBRuICwgOwAQBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWgg+CcIQsKYNMg?= =?us-ascii?q?RsFlxMBjViBXoRDiFyFZIhsASABAUKECnKEWYEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,546,1444694400"; d="scan'208";a="62050819" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2016 22:04:53 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u09M4rwa013648 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 22:04:53 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 9 Jan 2016 16:04:52 -0600 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1104.009; Sat, 9 Jan 2016 16:04:52 -0600 From: "Darrel Lewis (darlewis)" To: Luigi Iannone Thread-Topic: [lisp] Update Proposed CHarter Thread-Index: AQHRSynDYZSVkjMIzkGRRLkXeytrfg== Date: Sat, 9 Jan 2016 22:04:52 +0000 Message-ID: <28FB99DA-206A-4C95-AF85-4C5328DAB02A@cisco.com> References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> In-Reply-To: <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> 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.113.119] Content-Type: text/plain; charset="Windows-1252" Content-ID: <52AF553A01276C4E91D4B8E80675299E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: LISP mailing list list , Joel Halpern Direct Subject: Re: [lisp] Update Proposed CHarter 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, 09 Jan 2016 22:04:56 -0000 Luigi, Where would enhancements of the protocol - like Reliable Transport - fit in= to the below text? I=92d like to make sure that things like this and a pub= /sub distribution model are explicitly mentioned, because they are actively= being developed by multiple implementers - maybe =91alternative Mapping Sy= stem Design=92 is too narrow a focus? -Darrel On Jan 6, 2016, at 6:42 AM, Luigi Iannone wrote: > Hi All, >=20 > Hereafter a new version of the charter with the comments received so far. >=20 > Please send more feedback. Would be good if we can send the charter to ou= r AD by next week. >=20 > ciao >=20 > L. >=20 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >=20 >=20 > The LISP WG has completed the first set of Experimental RFCs describing t= he Locator/ID Separation Protocol (LISP). LISP supports a routing architect= ure which decouples the routing locators and identifiers, thus allowing for= efficient aggregation of the routing locator space and providing persisten= t identifiers in the identifier space. LISP requires no changes to end-syst= ems or to routers that do not directly participate in the LISP deployment. = LISP aims for an incrementally deployable protocol. The scope of the LISP t= echology is recognized to range from unicast and multicast overlays at Laye= r 2 as well as at Layer 3, including NAT traversal, VPNs, and supporting m= obility as a general feature, independently of wheter it is a mobile user o= r a migrating VM, hence being applicable in both Data Centers and public In= ternet environments. >=20 >=20 > The LISP WG is chartered to continue work on the LISP base protocol with = the main objective to develop a standard solution based on the completed Ex= perimental RFCs and the experience gained from early deployments. >=20 > This work will include reviewing the existing set of Experimental RFCs an= d doing the necessary enhancements to support a base set of standards track= RFCs. The group will review the current set of Working Group documents to = identify potential standards-track documents and do the necessary enhanceme= nts to support standards-track. It is recognized that some of the work will= continue on the experimental track, though the group is encouraged to move= the documents to standards track in support of network use, whereas the wo= rk previously was scoped to experimental documents. >=20 > Beside this main focus, the LISP WG work on the following items: >=20 > =B7 Multi-protocol support: Specifying the required extensions to s= upport multi-protocol encapsulation (e.g., L2 or NSH =96 Network Service = Headers). Rather than developing new encapsulations the work will aim at us= ing existing well-established encapsulations or emerging from other Working= Grops such as NVO3 and SFC. =20 >=20 > =B7 Alternative Mapping System Design. By extenting LISP with new = protocols support it is also necessary to develop the required mapping func= tion and control plane extensions to operate LISP map-assisted networks (w= hich might include Hierarchical Pull, Publish/Subscribe, or Push models, in= dependednt mapping systems interconnection, security extensions, or alterna= tive transports of the LISP control protocol). >=20 > =B7 Mobility >=20 > =B7 Multicast: Support for overlay multicast by means of replicatio= n as well as interfacing with existing underlay multicast support. >=20 > =B7 Data-Plane Encryption >=20 > =B7 NAT-Traversal >=20 > =B7 Models for managing the LISP protocol and deployments that incl= ude data models, as well as allowing for programmable management interfaces= . These managament methods should be considered for both the data-plane, co= ntrol-plane, and mapping system components. >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jan 11 06:00:44 2016 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 1F23C1A00B0 for ; Mon, 11 Jan 2016 06:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.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 ou5obgwBmVpQ for ; Mon, 11 Jan 2016 06:00:41 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 377421A00CF for ; Mon, 11 Jan 2016 06:00:41 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id f206so269930182wmf.0 for ; Mon, 11 Jan 2016 06:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e2aZCk4utBnCqLMal+u0i3oWw6sGafjrS0O1WLs/iR0=; b=svSvT0YiE3/PudFcPobvBzQTHgyB0xklE4633gbYtEwUKFFvHTjxz5zfAy0ecyTqjW q+hSxmm5ut8FXGwUpVuMR/EuvObSTYQshEqUPfSnfMcqEWpW0mv0XuHDyTKt9kNnlt00 o0htmmJL6apVqEAOlI10Ew3eRT0zL8o6UUvd6xHXD530nrCbPWZixCqSGonhT+iDmRA2 qRmhbKxDbZbOn7T9iuS8UpamcBJbY8C1HcTNF3jKL/bGY64ugI2RKVzRwQ4Vp93kXFGr qi1u8IN93RJ6LvwAsMUlj6c19GTQrw0ANzTRhRLi0NzouDUdr74AGwewGeuCaTeGh+e1 3/yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=e2aZCk4utBnCqLMal+u0i3oWw6sGafjrS0O1WLs/iR0=; b=DM8IdnSrXrMGLtiNO0x3ww6brGPoEmC4SpbB/txh2qvKKaiJHCwvT8j8YHMLd6cP3l HYcm3EVsLn78GsAn95LhYAnDQGxKnwqwz2ksngn6IcC9sXo6mj11x8ZKhOxwZ7D2xW53 wdr/mRkN8Lm6++s8aKXvuUnqogp6JSzRjqWeyZLQj0/v6aLK8WfOJvGDakSm1sgXuWpS UsVY856u4qXy8jn87UoHA5Gb7YvYI4M2ABiuRGKtNJNgsm2BzU0UnkZxaHCk+w6RU69I Ol7Z0ohSZWx4aLbqSOpqawoUROhWgHU/kEsA1lmJVxuCyQbBZwitgwxcQe7vWCNL95el ASdg== X-Gm-Message-State: ALoCoQnlU0e3jRE6+5A1hQgHQLVrkZnB5uqSCNmPedzhtXAgvc88aLiP9UhXHeAkEMYEtAZtdpDlVVbs7+R1SMo8Nj7XlDBWiQ== X-Received: by 10.28.156.198 with SMTP id f189mr12988401wme.25.1452520839711; Mon, 11 Jan 2016 06:00:39 -0800 (PST) Received: from dhcp164-132.enst.fr (dhcp164-132.enst.fr. [137.194.165.132]) by smtp.gmail.com with ESMTPSA id f205sm13004794wme.4.2016.01.11.06.00.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jan 2016 06:00:38 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <28FB99DA-206A-4C95-AF85-4C5328DAB02A@cisco.com> Date: Mon, 11 Jan 2016 15:00:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94443448-C4FC-4616-BF64-BBA87743235C@gigix.net> References: <08A51E69-008C-4DBE-9707-996468F46FC3@gigix.net> <709F769A-B270-4DB9-AF61-FF9FCFA0B790@gigix.net> <28FB99DA-206A-4C95-AF85-4C5328DAB02A@cisco.com> To: "Darrel Lewis (darlewis)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Update Proposed CHarter 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, 11 Jan 2016 14:00:43 -0000 Hi Darrel, I am not sure I follow your comment.=20 Both Pub/Sub and reliable transport are mentioned in the proposed draft. Can you elaborate a bit what in your opinion is missing? Ciao L. > On 09 Jan 2016, at 23:04, Darrel Lewis (darlewis) = wrote: >=20 > Luigi, >=20 > Where would enhancements of the protocol - like Reliable Transport - = fit into the below text? I=92d like to make sure that things like this = and a pub/sub distribution model are explicitly mentioned, because they = are actively being developed by multiple implementers - maybe = =91alternative Mapping System Design=92 is too narrow a focus? >=20 > -Darrel > On Jan 6, 2016, at 6:42 AM, Luigi Iannone wrote: >=20 >> Hi All, >>=20 >> Hereafter a new version of the charter with the comments received so = far. >>=20 >> Please send more feedback. Would be good if we can send the charter = to our AD by next week. >>=20 >> ciao >>=20 >> L. >>=20 >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>=20 >>=20 >> The LISP WG has completed the first set of Experimental RFCs = describing the Locator/ID Separation Protocol (LISP). LISP supports a = routing architecture which decouples the routing locators and = identifiers, thus allowing for efficient aggregation of the routing = locator space and providing persistent identifiers in the identifier = space. LISP requires no changes to end-systems or to routers that do not = directly participate in the LISP deployment. LISP aims for an = incrementally deployable protocol. The scope of the LISP techology is = recognized to range from unicast and multicast overlays at Layer 2 as = well as at Layer 3, including NAT traversal, VPNs, and supporting = mobility as a general feature, independently of wheter it is a mobile = user or a migrating VM, hence being applicable in both Data Centers and = public Internet environments. >>=20 >>=20 >> The LISP WG is chartered to continue work on the LISP base protocol = with the main objective to develop a standard solution based on the = completed Experimental RFCs and the experience gained from early = deployments. >>=20 >> This work will include reviewing the existing set of Experimental = RFCs and doing the necessary enhancements to support a base set of = standards track RFCs. The group will review the current set of Working = Group documents to identify potential standards-track documents and do = the necessary enhancements to support standards-track. It is recognized = that some of the work will continue on the experimental track, though = the group is encouraged to move the documents to standards track in = support of network use, whereas the work previously was scoped to = experimental documents. >>=20 >> Beside this main focus, the LISP WG work on the following items: >>=20 >> =B7 Multi-protocol support: Specifying the required extensions = to support multi-protocol encapsulation (e.g., L2 or NSH =96 Network = Service Headers). Rather than developing new encapsulations the work = will aim at using existing well-established encapsulations or emerging = from other Working Grops such as NVO3 and SFC. =20 >>=20 >> =B7 Alternative Mapping System Design. By extenting LISP with = new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independednt mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). >>=20 >> =B7 Mobility >>=20 >> =B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. >>=20 >> =B7 Data-Plane Encryption >>=20 >> =B7 NAT-Traversal >>=20 >> =B7 Models for managing the LISP protocol and deployments that = include data models, as well as allowing for programmable management = interfaces. These managament methods should be considered for both the = data-plane, control-plane, and mapping system components. >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Fri Jan 15 01:14:37 2016 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 8413D1A8AED for ; Fri, 15 Jan 2016 01:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 nV6Ril4JRnBi for ; Fri, 15 Jan 2016 01:14:33 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 8DD4C1A8AE8 for ; Fri, 15 Jan 2016 01:14:33 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id l65so12030433wmf.1 for ; Fri, 15 Jan 2016 01:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=cUx/HWsIDPKRyiNwImS5/BFkh4eOlXuA+2uF/DQjo+Q=; b=NE1Q0YL3l+brtO00uF+v3HyEpdmQlND+ssUbL9Dw7+ITC/iq7ssZOHck6Xaw8F3mVh w1f8pNCnVbbAMbN6JdhRLkIQfk4B/0s9tLxXBs7CBC84RUIhfVSxO0x1rjiSxpys4IsT ifq1YDKiP3QTpKoGCHyPc4PPMjxvNzrudF/bE9j6TSjgJeh+7mibwTwBocyCyXXxgT8T MCBRQs+MaOR8QvzmDvW3zy55986RQ/ZdYPnofamsTBs8UYyHx5J7saZ/VF2JaJjvUlu4 zR97QfLmN1TQCA6G20uzF+uPNhCyA124A0t4QSMkGK9y/sBUoTfs9d8LGoNB35TWDwRY mm6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version; bh=cUx/HWsIDPKRyiNwImS5/BFkh4eOlXuA+2uF/DQjo+Q=; b=aRTEjjdE+SMjiIbOEVRTbsGScujt04UtK9yMWt2lTUVEnYAqzLOUAkyHecH0jckH5K H0B/zoU/4/WFCNuxQL4gSYQbXGfz54lG6IMyVcKvSRmZ52FyLLnGNURKknxrSYq+hMRo 3Djl7sS5CKqsQprEiLJ5eUO0FpNidh+imXRqZYoRcnzSeOjtKlf2u8Il33VEULdH80IV CeXiy08XZ1qTzrsyBsFq4A/sGDqAWDs6hWkf95M1Wz0187uQaA3WP0wNQ5mDauXA/pgb 56xsGi4Hr2uupBp8WjkxoADNdCx1SXjUES2FA2+gibFpzz9uptbs/TbqKUWC9lwShR1x Wagw== X-Gm-Message-State: AG10YORqcFHxjKpvh8JPK0+LvP35I1MHQPJ4eKKTIKVyxmFDCzU8Pk+piVMNinND9nOILQ== X-Received: by 10.28.22.199 with SMTP id 190mr2260759wmw.54.1452849272144; Fri, 15 Jan 2016 01:14:32 -0800 (PST) Received: from [10.9.1.109] (napsach022.hosting-cea.net. [192.54.209.59]) by smtp.gmail.com with ESMTPSA id x10sm9708818wjx.8.2016.01.15.01.14.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 01:14:30 -0800 (PST) From: Luigi Iannone Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jan 2016 10:14:37 +0100 Message-Id: To: "BRUNGARD, DEBORAH A" , Joel Halpern Direct Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: LISP mailing list list Subject: [lisp] Proposed LISP WG Charter 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, 15 Jan 2016 09:14:35 -0000 Hi Deborah, The LISP WG had a final round of discussion (on the mailing list)=20 earlier this month on the new proposed charter. Hereafter you can find the outcome. This version includes all items the WG is ready to work on. thanks ciao Luigi %%%%%%%% LISP WG PROPOSED CHARTER = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The LISP WG has completed the first set of Experimental RFCs describing = the Locator/ID Separation Protocol (LISP). LISP supports a routing = architecture which decouples the routing locators and identifiers, thus = allowing for efficient aggregation of the routing locator space and = providing persistent identifiers in the identifier space. LISP requires = no changes to end-systems or to routers that do not directly participate = in the LISP deployment. LISP aims for an incrementally deployable = protocol. The scope of the LISP techology is recognized to range from = unicast and multicast overlays at Layer 2 as well as at Layer 3, = including NAT traversal, VPNs, and supporting mobility as a general = feature, independently of wheter it is a mobile user or a migrating VM, = hence being applicable in both Data Centers and public Internet = environments. The LISP WG is chartered to continue work on the LISP base protocol with = the main objective to develop a standard solution based on the completed = Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs = and doing the necessary enhancements to support a base set of standards = track RFCs. The group will review the current set of Working Group = documents to identify potential standards-track documents and do the = necessary enhancements to support standards-track. It is recognized that = some of the work will continue on the experimental track, though the = group is encouraged to move the documents to standards track in support = of network use, whereas the work previously was scoped to experimental = documents. Beside this main focus, the LISP WG work on the following items: =C2=B7 Multi-protocol support: Specifying the required extensions = to support multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service Headers). Rather than developing new encapsulations the = work will aim at using existing well-established encapsulations or = emerging from other Working Grops such as NVO3 and SFC. =20 =C2=B7 Alternative Mapping System Design. By extenting LISP with = new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independent mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). =C2=B7 Mobility =C2=B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. =C2=B7 Data-Plane Encryption =C2=B7 NAT-Traversal =C2=B7 Models for managing the LISP protocol and deployments that = include data models, as well as allowing for programmable management = interfaces. These managament methods should be considered for both the = data-plane, control-plane, and mapping system components. From nobody Tue Jan 19 04:07:22 2016 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 E8F801B2D0E; Tue, 19 Jan 2016 04:07:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 04:07:20 -0800 Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, lisp-chairs@ietf.org Subject: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 19 Jan 2016 12:07:21 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lisp-threats-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for doing this document. I think it's a useful part of the LISP documentation set. general: I think you underestimate the purely passive threats - my point on 2.2 below was almost a DISCUSS but given the WG have already adopted draft-ietf-lisp-crypto I figured there's no need to try block this. I would really encourage you to consider the threats that are mitigated by that specification here, even if those threats weren't initially considered as being that relevant to LISP (when the work on LISP began I mean). If that had been done already in this draft, I'd have been a YES ballot, if that makes any difference;-) - intro: I think you should add a few caveats here to say that you're not covering threats due to specific implementations and also that the text here captures only those LISP-specific threats we know about today and that more *will* be discovered as deployment continues. - intro: you don't write about DNS here, but if some LISP configuration settings use DNS names then via DNS with no DNSSEC an attacker can decide to be on-path sometimes, off-path other times. That (or similar) might be a nice way to illustrate the scope here, while also alerting the implementer to other threats that might affect their implementations. - 2.1 I think it'd be valuable to say that the 2.1.x sections are really just for the sake of exposition - we cannot assume that all attackers fall into any neat category. You do note this (more or less) in 2.1.5 but I think that'd be better done in 2.1. The reason to suggest this change is that being open to attackers not conforming to our descriptions is important. - 2.2 - which section here covers purely passive monitoring? All the 2.2.x seem to only cover active attacks. (I'd also suggest moving the 2.2.10 text to 2.2 similarly to the suggestion above for 2.1.) - 3.8 - you probably need to note somewhere (not sure where) that a bad PRNG would improve the attacker's chances in various ways. I think a calculation of the probability of a nonce collision (for both a good and not-good PRNG) could be a useful addition. - 3.8, 3rd para: I would argue that this threat is a "core" point to be made, as it's arguably the main LISP-specific threat and ought be emphasised more, e.g. via a mention and pointer in the introduction, or otherwise. - section 4 is pretty weak to be honest. I think you could at least recognise that LISP, as with any mechanism that concentrates traffic (between xTRs) means that passively monitoring plaintext is easier than before and that there is therefore value in encrypting the traffic between xTRs as is proposed in draft-ietf-lisp-crypto - (nit) section 5 has a really odd sentence " The usage will be designed and defined specific for the needs of the specification." I've no idea what that means TBH. From nobody Tue Jan 19 06:51:36 2016 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 A72181B2FDA; Tue, 19 Jan 2016 06:51:31 -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 flpWKBBn_v_U; Tue, 19 Jan 2016 06:51:29 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73951B2FDB; Tue, 19 Jan 2016 06:51:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 388131C01A6; Tue, 19 Jan 2016 06:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1453215089; bh=guyILfEGWokfpGUPCxmKWZE0JV3sJcGTAYbHQ3BJGvI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=WHXfp8FSTssXPZ4OAOsGbeOPGPkVNq9oEWFVtDN8vnyzGTBLSRFmxG41XfWVJNE/5 ak19388KrnqJOmji/ibGqDsA4dKAqN+v6uvIyAeT7jzOXkkhXslU73byirbvjhxBxE swq2ytSV7czvGtgJFxiippKvbn8c0huvgASQX3k8= X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 8ABA31C08A3; Tue, 19 Jan 2016 06:51:28 -0800 (PST) To: Stephen Farrell , The IESG References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <569E4D30.5050807@joelhalpern.com> Date: Tue, 19 Jan 2016 09:50:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, lisp-chairs@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 19 Jan 2016 14:51:31 -0000 Stephen, than you for the comments. With regard to the question of discussing lisp-crypto, the biggest concern has been creating a normative dependence on future work. The charter item was to discuss threats against LISP as documented already. I would like to see the crypto work covered, but it seems incorrect to the charter and likely to cause a further significant delay in an overdue document. Yours, Joel On 1/19/16 7:07 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-lisp-threats-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for doing this document. I think it's a useful part > of the LISP documentation set. > > general: I think you underestimate the purely passive > threats - my point on 2.2 below was almost a DISCUSS but > given the WG have already adopted draft-ietf-lisp-crypto I > figured there's no need to try block this. I would really > encourage you to consider the threats that are mitigated by > that specification here, even if those threats weren't > initially considered as being that relevant to LISP (when > the work on LISP began I mean). If that had been done > already in this draft, I'd have been a YES ballot, if that > makes any difference;-) > > - intro: I think you should add a few caveats here to say > that you're not covering threats due to specific > implementations and also that the text here captures only > those LISP-specific threats we know about today and that > more *will* be discovered as deployment continues. > > - intro: you don't write about DNS here, but if some LISP > configuration settings use DNS names then via DNS with no > DNSSEC an attacker can decide to be on-path sometimes, > off-path other times. That (or similar) might be a nice way > to illustrate the scope here, while also alerting the > implementer to other threats that might affect their > implementations. > > - 2.1 I think it'd be valuable to say that the 2.1.x > sections are really just for the sake of exposition - we > cannot assume that all attackers fall into any neat > category. You do note this (more or less) in 2.1.5 but I > think that'd be better done in 2.1. The reason to suggest > this change is that being open to attackers not conforming > to our descriptions is important. > > - 2.2 - which section here covers purely passive monitoring? > All the 2.2.x seem to only cover active attacks. (I'd also > suggest moving the 2.2.10 text to 2.2 similarly to the > suggestion above for 2.1.) > > - 3.8 - you probably need to note somewhere (not sure where) > that a bad PRNG would improve the attacker's chances in > various ways. I think a calculation of the probability of a > nonce collision (for both a good and not-good PRNG) could be > a useful addition. > > - 3.8, 3rd para: I would argue that this threat is a "core" > point to be made, as it's arguably the main LISP-specific > threat and ought be emphasised more, e.g. via a mention and > pointer in the introduction, or otherwise. > > - section 4 is pretty weak to be honest. I think you could > at least recognise that LISP, as with any mechanism that > concentrates traffic (between xTRs) means that passively > monitoring plaintext is easier than before and that there is > therefore value in encrypting the traffic between xTRs as is > proposed in draft-ietf-lisp-crypto > > - (nit) section 5 has a really odd sentence " The usage will > be designed and defined specific for the needs of the > specification." I've no idea what that means TBH. > > > From nobody Tue Jan 19 06:56:56 2016 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 05F3C1B2FF5; Tue, 19 Jan 2016 06:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LvDNGjZEzcY; Tue, 19 Jan 2016 06:56:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27C91B2FF2; Tue, 19 Jan 2016 06:56:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9D993BEA0; Tue, 19 Jan 2016 14:56:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwWSUTm7mGEK; Tue, 19 Jan 2016 14:56:51 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.20.159]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3556CBE73; Tue, 19 Jan 2016 14:56:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453215410; bh=jSNaVCeyEmJ68AMZ1/vbF5Z7NFfK627xRHDKFxT9uzY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bcWxgeCaq5ACT7khBzgg7mWzFAUIQEh3pNZ+l7MwiGxqGgX0sWMNiZIyZz7uig5yZ XuUZGCHzFnkia5M5IW6PTXMGSJaPDLRj9qxJYdMgwUKnG6XgSHd/4PvooW5Bqqua16 PxPYaW+T6/iYx79IaPqHRrZbhnVwXtiCpjKeafSM= To: "Joel M. Halpern" , The IESG References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <569E4EB1.2060807@cs.tcd.ie> Date: Tue, 19 Jan 2016 14:56:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569E4D30.5050807@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, lisp-chairs@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 19 Jan 2016 14:56:56 -0000 On 19/01/16 14:50, Joel M. Halpern wrote: > Stephen, than you for the comments. > > With regard to the question of discussing lisp-crypto, the biggest > concern has been creating a normative dependence on future work. Then make it informative I guess. I don't see any problem, and do see benefits, in text along the lines of "privacy is an issue since LISP concentrates traffic making passive monitoring of plaintext arguably somewhat easier, people are working on [list-crypto] as a way to deal with that." In any case, you shouldn't take anything I've said as me wanting a normative reference to lisp-crypto, I didn't mean to suggest that. As that's how you've handled lisp-sec it shouldn't pose any process issues I'd hope. That said, I'm not a DISCUSS on this, so am non-blocking. Cheers, S. > The > charter item was to discuss threats against LISP as documented already. > I would like to see the crypto work covered, but it seems incorrect to > the charter and likely to cause a further significant delay in an > overdue document. > > Yours, > Joel > > On 1/19/16 7:07 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-lisp-threats-14: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Thanks for doing this document. I think it's a useful part >> of the LISP documentation set. >> >> general: I think you underestimate the purely passive >> threats - my point on 2.2 below was almost a DISCUSS but >> given the WG have already adopted draft-ietf-lisp-crypto I >> figured there's no need to try block this. I would really >> encourage you to consider the threats that are mitigated by >> that specification here, even if those threats weren't >> initially considered as being that relevant to LISP (when >> the work on LISP began I mean). If that had been done >> already in this draft, I'd have been a YES ballot, if that >> makes any difference;-) >> >> - intro: I think you should add a few caveats here to say >> that you're not covering threats due to specific >> implementations and also that the text here captures only >> those LISP-specific threats we know about today and that >> more *will* be discovered as deployment continues. >> >> - intro: you don't write about DNS here, but if some LISP >> configuration settings use DNS names then via DNS with no >> DNSSEC an attacker can decide to be on-path sometimes, >> off-path other times. That (or similar) might be a nice way >> to illustrate the scope here, while also alerting the >> implementer to other threats that might affect their >> implementations. >> >> - 2.1 I think it'd be valuable to say that the 2.1.x >> sections are really just for the sake of exposition - we >> cannot assume that all attackers fall into any neat >> category. You do note this (more or less) in 2.1.5 but I >> think that'd be better done in 2.1. The reason to suggest >> this change is that being open to attackers not conforming >> to our descriptions is important. >> >> - 2.2 - which section here covers purely passive monitoring? >> All the 2.2.x seem to only cover active attacks. (I'd also >> suggest moving the 2.2.10 text to 2.2 similarly to the >> suggestion above for 2.1.) >> >> - 3.8 - you probably need to note somewhere (not sure where) >> that a bad PRNG would improve the attacker's chances in >> various ways. I think a calculation of the probability of a >> nonce collision (for both a good and not-good PRNG) could be >> a useful addition. >> >> - 3.8, 3rd para: I would argue that this threat is a "core" >> point to be made, as it's arguably the main LISP-specific >> threat and ought be emphasised more, e.g. via a mention and >> pointer in the introduction, or otherwise. >> >> - section 4 is pretty weak to be honest. I think you could >> at least recognise that LISP, as with any mechanism that >> concentrates traffic (between xTRs) means that passively >> monitoring plaintext is easier than before and that there is >> therefore value in encrypting the traffic between xTRs as is >> proposed in draft-ietf-lisp-crypto >> >> - (nit) section 5 has a really odd sentence " The usage will >> be designed and defined specific for the needs of the >> specification." I've no idea what that means TBH. >> >> >> > From nobody Tue Jan 19 14:59:00 2016 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 3B4761B376E for ; Tue, 19 Jan 2016 14:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4AMT652I0AQ for ; Tue, 19 Jan 2016 14:58:56 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137211B376D for ; Tue, 19 Jan 2016 14:58:56 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u0JMwtvU030480; Tue, 19 Jan 2016 17:58:55 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 20fjq8nw4j-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Jan 2016 17:58:54 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u0JMwrTX026989; Tue, 19 Jan 2016 17:58:53 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u0JMwjhV026907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 17:58:50 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 19 Jan 2016 22:58:36 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.106]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Tue, 19 Jan 2016 17:58:36 -0500 From: "BRUNGARD, DEBORAH A" To: Luigi Iannone , Joel Halpern Direct Thread-Topic: Proposed LISP WG Charter Thread-Index: AQHRT3Upn000fbO/oEKkNos4wAzRfZ8DeZMw Date: Tue, 19 Jan 2016 22:58:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.146.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-19_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601190399 Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Proposed LISP WG Charter 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, 19 Jan 2016 22:58:58 -0000 SGkgTHVpZ2ksDQoNCkxvb2tzIGdvb2QgLSBjYW4geW91IGFkZCBhIGZldyB3b3JkcyB0byBzY29w ZSBiZXR0ZXIgdGhlIHRocmVlIGJ1bGxldCBpdGVtczogbW9iaWxpdHksIGRhdGEtcGxhbmUgZW5j cnlwdGlvbiwgTkFULVRyYXZlcnNhbD8NCg0KVGhhbmtzLA0KRGVib3JhaA0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMdWlnaSBJYW5ub25lIFttYWlsdG86Z2d4QGdpZ2l4 Lm5ldF0gDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTUsIDIwMTYgNDoxNSBBTQ0KVG86IEJSVU5H QVJELCBERUJPUkFIIEEgPGRiMzU0NkBhdHQuY29tPjsgSm9lbCBIYWxwZXJuIERpcmVjdCA8am1o LmRpcmVjdEBqb2VsaGFscGVybi5jb20+DQpDYzogTElTUCBtYWlsaW5nIGxpc3QgbGlzdCA8bGlz cEBpZXRmLm9yZz4NClN1YmplY3Q6IFByb3Bvc2VkIExJU1AgV0cgQ2hhcnRlcg0KDQpIaSBEZWJv cmFoLA0KDQpUaGUgTElTUCBXRyBoYWQgYSBmaW5hbCByb3VuZCBvZiBkaXNjdXNzaW9uIChvbiB0 aGUgbWFpbGluZyBsaXN0KSANCmVhcmxpZXIgdGhpcyBtb250aCBvbiB0aGUgbmV3IHByb3Bvc2Vk IGNoYXJ0ZXIuDQoNCkhlcmVhZnRlciB5b3UgY2FuIGZpbmQgdGhlIG91dGNvbWUuDQpUaGlzIHZl cnNpb24gaW5jbHVkZXMgYWxsIGl0ZW1zIHRoZSBXRyBpcyByZWFkeSB0byB3b3JrIG9uLg0KDQp0 aGFua3MNCg0KY2lhbw0KDQpMdWlnaQ0KDQoNCiUlJSUlJSUlIExJU1AgV0cgUFJPUE9TRUQgQ0hB UlRFUiAlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUNCg0KDQpUaGUgTElT UCBXRyBoYXMgY29tcGxldGVkIHRoZSBmaXJzdCBzZXQgb2YgRXhwZXJpbWVudGFsIFJGQ3MgZGVz Y3JpYmluZyB0aGUgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKS4gTElTUCBz dXBwb3J0cyBhIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIHdoaWNoIGRlY291cGxlcyB0aGUgcm91dGlu ZyBsb2NhdG9ycyBhbmQgaWRlbnRpZmllcnMsIHRodXMgYWxsb3dpbmcgZm9yIGVmZmljaWVudCBh Z2dyZWdhdGlvbiBvZiB0aGUgcm91dGluZyBsb2NhdG9yIHNwYWNlIGFuZCBwcm92aWRpbmcgcGVy c2lzdGVudCBpZGVudGlmaWVycyBpbiB0aGUgaWRlbnRpZmllciBzcGFjZS4gTElTUCByZXF1aXJl cyBubyBjaGFuZ2VzIHRvIGVuZC1zeXN0ZW1zIG9yIHRvIHJvdXRlcnMgdGhhdCBkbyBub3QgZGly ZWN0bHkgcGFydGljaXBhdGUgaW4gdGhlIExJU1AgZGVwbG95bWVudC4gTElTUCBhaW1zIGZvciBh biBpbmNyZW1lbnRhbGx5IGRlcGxveWFibGUgcHJvdG9jb2wuIFRoZSBzY29wZSBvZiB0aGUgTElT UCB0ZWNob2xvZ3kgaXMgcmVjb2duaXplZCB0byByYW5nZSBmcm9tIHVuaWNhc3QgYW5kIG11bHRp Y2FzdCBvdmVybGF5cyBhdCBMYXllciAyIGFzIHdlbGwgYXMgYXQgTGF5ZXIgMywgaW5jbHVkaW5n IE5BVCB0cmF2ZXJzYWwsIFZQTnMsICBhbmQgc3VwcG9ydGluZyBtb2JpbGl0eSBhcyBhIGdlbmVy YWwgZmVhdHVyZSwgaW5kZXBlbmRlbnRseSBvZiB3aGV0ZXIgaXQgaXMgYSBtb2JpbGUgdXNlciBv ciBhIG1pZ3JhdGluZyBWTSwgaGVuY2UgYmVpbmcgYXBwbGljYWJsZSBpbiBib3RoIERhdGEgQ2Vu dGVycyBhbmQgcHVibGljIEludGVybmV0IGVudmlyb25tZW50cy4NCg0KDQpUaGUgTElTUCBXRyBp cyBjaGFydGVyZWQgdG8gY29udGludWUgd29yayBvbiB0aGUgTElTUCBiYXNlIHByb3RvY29sIHdp dGggdGhlIG1haW4gb2JqZWN0aXZlIHRvIGRldmVsb3AgYSBzdGFuZGFyZCBzb2x1dGlvbiBiYXNl ZCBvbiB0aGUgY29tcGxldGVkIEV4cGVyaW1lbnRhbCBSRkNzIGFuZCB0aGUgZXhwZXJpZW5jZSBn YWluZWQgZnJvbSBlYXJseSBkZXBsb3ltZW50cy4NCg0KVGhpcyB3b3JrIHdpbGwgaW5jbHVkZSBy ZXZpZXdpbmcgdGhlIGV4aXN0aW5nIHNldCBvZiBFeHBlcmltZW50YWwgUkZDcyBhbmQgZG9pbmcg dGhlIG5lY2Vzc2FyeSBlbmhhbmNlbWVudHMgdG8gc3VwcG9ydCBhIGJhc2Ugc2V0IG9mIHN0YW5k YXJkcyB0cmFjayBSRkNzLiBUaGUgZ3JvdXAgd2lsbCByZXZpZXcgdGhlIGN1cnJlbnQgc2V0IG9m IFdvcmtpbmcgR3JvdXAgZG9jdW1lbnRzIHRvIGlkZW50aWZ5IHBvdGVudGlhbCBzdGFuZGFyZHMt dHJhY2sgZG9jdW1lbnRzIGFuZCBkbyB0aGUgbmVjZXNzYXJ5IGVuaGFuY2VtZW50cyB0byBzdXBw b3J0IHN0YW5kYXJkcy10cmFjay4gSXQgaXMgcmVjb2duaXplZCB0aGF0IHNvbWUgb2YgdGhlIHdv cmsgd2lsbCBjb250aW51ZSBvbiB0aGUgZXhwZXJpbWVudGFsIHRyYWNrLCB0aG91Z2ggdGhlIGdy b3VwIGlzIGVuY291cmFnZWQgdG8gbW92ZSB0aGUgZG9jdW1lbnRzIHRvIHN0YW5kYXJkcyB0cmFj ayBpbiBzdXBwb3J0IG9mIG5ldHdvcmsgdXNlLCB3aGVyZWFzIHRoZSB3b3JrIHByZXZpb3VzbHkg d2FzIHNjb3BlZCB0byBleHBlcmltZW50YWwgZG9jdW1lbnRzLg0KDQpCZXNpZGUgdGhpcyBtYWlu IGZvY3VzLCB0aGUgTElTUCBXRyB3b3JrIG9uIHRoZSBmb2xsb3dpbmcgaXRlbXM6DQoNCsK3ICAg ICAgIE11bHRpLXByb3RvY29sIHN1cHBvcnQ6IFNwZWNpZnlpbmcgdGhlIHJlcXVpcmVkIGV4dGVu c2lvbnMgdG8gc3VwcG9ydCBtdWx0aS1wcm90b2NvbCBlbmNhcHN1bGF0aW9uIChlLmcuLCAgIEwy IG9yIE5TSCDigJMgTmV0d29yayBTZXJ2aWNlIEhlYWRlcnMpLiBSYXRoZXIgdGhhbiBkZXZlbG9w aW5nIG5ldyBlbmNhcHN1bGF0aW9ucyB0aGUgd29yayB3aWxsIGFpbSBhdCB1c2luZyBleGlzdGlu ZyB3ZWxsLWVzdGFibGlzaGVkIGVuY2Fwc3VsYXRpb25zIG9yIGVtZXJnaW5nIGZyb20gb3RoZXIg V29ya2luZyBHcm9wcyBzdWNoIGFzICBOVk8zIGFuZCBTRkMuICANCg0KwrcgICAgICAgQWx0ZXJu YXRpdmUgTWFwcGluZyBTeXN0ZW0gRGVzaWduLiBCeSBleHRlbnRpbmcgTElTUCB3aXRoICBuZXcg cHJvdG9jb2xzIHN1cHBvcnQgaXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gZGV2ZWxvcCB0aGUgcmVx dWlyZWQgbWFwcGluZyBmdW5jdGlvbiBhbmQgY29udHJvbCBwbGFuZSBleHRlbnNpb25zIHRvIG9w ZXJhdGUgTElTUCBtYXAtYXNzaXN0ZWQgIG5ldHdvcmtzICh3aGljaCBtaWdodCBpbmNsdWRlIEhp ZXJhcmNoaWNhbCBQdWxsLCBQdWJsaXNoL1N1YnNjcmliZSwgb3IgUHVzaCBtb2RlbHMsIGluZGVw ZW5kZW50IG1hcHBpbmcgc3lzdGVtcyBpbnRlcmNvbm5lY3Rpb24sIHNlY3VyaXR5IGV4dGVuc2lv bnMsIG9yIGFsdGVybmF0aXZlIHRyYW5zcG9ydHMgb2YgdGhlIExJU1AgY29udHJvbCBwcm90b2Nv bCkuDQoNCsK3ICAgICAgIE1vYmlsaXR5DQoNCsK3ICAgICAgIE11bHRpY2FzdDogU3VwcG9ydCBm b3Igb3ZlcmxheSBtdWx0aWNhc3QgYnkgbWVhbnMgb2YgcmVwbGljYXRpb24gYXMgd2VsbCBhcyBp bnRlcmZhY2luZyB3aXRoIGV4aXN0aW5nIHVuZGVybGF5IG11bHRpY2FzdCBzdXBwb3J0Lg0KDQrC tyAgICAgICBEYXRhLVBsYW5lIEVuY3J5cHRpb24NCg0KwrcgICAgICAgTkFULVRyYXZlcnNhbA0K DQrCtyAgICAgICBNb2RlbHMgZm9yIG1hbmFnaW5nIHRoZSBMSVNQIHByb3RvY29sIGFuZCBkZXBs b3ltZW50cyB0aGF0IGluY2x1ZGUgZGF0YSBtb2RlbHMsIGFzIHdlbGwgYXMgYWxsb3dpbmcgZm9y IHByb2dyYW1tYWJsZSBtYW5hZ2VtZW50IGludGVyZmFjZXMuIFRoZXNlIG1hbmFnYW1lbnQgbWV0 aG9kcyBzaG91bGQgYmUgY29uc2lkZXJlZCBmb3IgYm90aCB0aGUgZGF0YS1wbGFuZSwgY29udHJv bC1wbGFuZSwgYW5kIG1hcHBpbmcgc3lzdGVtIGNvbXBvbmVudHMuDQoNCg== From nobody Wed Jan 20 03:01:11 2016 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 7E96E1B2A7A for ; Wed, 20 Jan 2016 03:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.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 blk8B3bGwP01 for ; Wed, 20 Jan 2016 03:01:05 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 7738C1B3A2C for ; Wed, 20 Jan 2016 03:01:05 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id 123so127663272wmz.0 for ; Wed, 20 Jan 2016 03:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3w05BYNSlvENN8HVvKjr54LNnjbSjJyoj29/d6gTrjg=; b=w2RtksZuKAa1tE6euNLQIjGlNQhXjfto1W5Sd5uNxgu9e2xCP0yOHhVpUWVsQSB0lG bFjjONnQOSGPoFOWUKb5rRbUpTSb6vIzTtdcUI9pohHaAeswdpJ2gUp/xg5USlmEhbYE sIY1l0lW1F8RdtteQ7GZElsh+sETYnDUD7SxaHpY/Eipnj5nzlFLLd4jql31sGZ3QidG 9xUg1gygc7GozgwbsHn2Ye34RglOzRDPaOST6xbhP7Oj+j1rEbSB7fr2dHiPE/G0O8P8 hIUaK1YMUsknRswzBY8SNVtrhTvZ2uot7iQvxjJNqt6faQQinHTc8btlf0JPC/2TEaO/ zryQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3w05BYNSlvENN8HVvKjr54LNnjbSjJyoj29/d6gTrjg=; b=F+rCt4bLGFexF+2lSKuuzTwBAwu3aGf4p9Ny37hZLXODTtzzNGWDptn0nFLl3L+1Ej /DxRoowImCegfu+UgHPYmPRsdPn9roEuIwqHGWR7vqKJXx/W1aX1N3exav4NX/CMkLPX sbtinSfvCytq7J08BuA1nd0gbk2GhX6qK4xpKIn2Had+ZA20w0K3QjN3JfWmhKdrtjAM mbGUbtaFZWri+/KHOYJfqIfclxOLKCM2NqoaqSQDWaF1TfvN64KQvNhEH77zmemgW3f8 F8pNtUkaio0uJoPqf73Crc+zftMtDqSn7ko5o07q+Om6wJmYnkmI73HIoMDFhHZk8l9w tDew== X-Gm-Message-State: AG10YOQS+SLwOfZktAFlESZX4Fas0XjDtu7oER7GYR4YNuJA0vA668C2PQkjNwIpJGmmLg== X-Received: by 10.28.228.87 with SMTP id b84mr3146563wmh.81.1453287664076; Wed, 20 Jan 2016 03:01:04 -0800 (PST) Received: from dhcp164-132.enst.fr (dhcp164-132.enst.fr. [137.194.165.132]) by smtp.gmail.com with ESMTPSA id 73sm24554346wmm.7.2016.01.20.03.01.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 03:01:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: Date: Wed, 20 Jan 2016 12:01:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Proposed LISP WG Charter 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, 20 Jan 2016 11:01:09 -0000 This can be surely be done. Will update the proposed charter before the end of the week. ciao L. > On 19 Jan 2016, at 23:58, BRUNGARD, DEBORAH A wrote: >=20 > Hi Luigi, >=20 > Looks good - can you add a few words to scope better the three bullet = items: mobility, data-plane encryption, NAT-Traversal? >=20 > Thanks, > Deborah >=20 >=20 > -----Original Message----- > From: Luigi Iannone [mailto:ggx@gigix.net]=20 > Sent: Friday, January 15, 2016 4:15 AM > To: BRUNGARD, DEBORAH A ; Joel Halpern Direct = > Cc: LISP mailing list list > Subject: Proposed LISP WG Charter >=20 > Hi Deborah, >=20 > The LISP WG had a final round of discussion (on the mailing list)=20 > earlier this month on the new proposed charter. >=20 > Hereafter you can find the outcome. > This version includes all items the WG is ready to work on. >=20 > thanks >=20 > ciao >=20 > Luigi >=20 >=20 > %%%%%%%% LISP WG PROPOSED CHARTER = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >=20 >=20 > The LISP WG has completed the first set of Experimental RFCs = describing the Locator/ID Separation Protocol (LISP). LISP supports a = routing architecture which decouples the routing locators and = identifiers, thus allowing for efficient aggregation of the routing = locator space and providing persistent identifiers in the identifier = space. LISP requires no changes to end-systems or to routers that do not = directly participate in the LISP deployment. LISP aims for an = incrementally deployable protocol. The scope of the LISP techology is = recognized to range from unicast and multicast overlays at Layer 2 as = well as at Layer 3, including NAT traversal, VPNs, and supporting = mobility as a general feature, independently of wheter it is a mobile = user or a migrating VM, hence being applicable in both Data Centers and = public Internet environments. >=20 >=20 > The LISP WG is chartered to continue work on the LISP base protocol = with the main objective to develop a standard solution based on the = completed Experimental RFCs and the experience gained from early = deployments. >=20 > This work will include reviewing the existing set of Experimental RFCs = and doing the necessary enhancements to support a base set of standards = track RFCs. The group will review the current set of Working Group = documents to identify potential standards-track documents and do the = necessary enhancements to support standards-track. It is recognized that = some of the work will continue on the experimental track, though the = group is encouraged to move the documents to standards track in support = of network use, whereas the work previously was scoped to experimental = documents. >=20 > Beside this main focus, the LISP WG work on the following items: >=20 > =C2=B7 Multi-protocol support: Specifying the required = extensions to support multi-protocol encapsulation (e.g., L2 or NSH = =E2=80=93 Network Service Headers). Rather than developing new = encapsulations the work will aim at using existing well-established = encapsulations or emerging from other Working Grops such as NVO3 and = SFC. =20 >=20 > =C2=B7 Alternative Mapping System Design. By extenting LISP with = new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independent mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). >=20 > =C2=B7 Mobility >=20 > =C2=B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. >=20 > =C2=B7 Data-Plane Encryption >=20 > =C2=B7 NAT-Traversal >=20 > =C2=B7 Models for managing the LISP protocol and deployments = that include data models, as well as allowing for programmable = management interfaces. These managament methods should be considered for = both the data-plane, control-plane, and mapping system components. >=20 From nobody Wed Jan 20 03:51:24 2016 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 6B5F51B3AA9 for ; Wed, 20 Jan 2016 03:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.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 EOUKn52vDV8J for ; Wed, 20 Jan 2016 03:51:20 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 E597E1B3AA8 for ; Wed, 20 Jan 2016 03:51:16 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id r129so127761259wmr.0 for ; Wed, 20 Jan 2016 03:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+qiOFhZR4jlCLuBeAREAPpPQ2xrw4kBNflTYbXXQpf8=; b=BtxOGyzANxi0nh0tYk/1aq+jR16VVL2OSsajqokiTgtBf2XplzlYmdqYdSHSRXujjO 4xe2Rc6Sm440/95h0vvNeQ7Z9E+JtoKSQy7J9rxXGiUSStqwC5tRsVbmAaS2AmBTqtYj lTSCPPc1+QSKkCrGR4BJWKujsdCbdBuzZvCS+1wsi7ZFZ7Z/+MQaIvbbWOfPaYphPLPU MeQW/ncRJgr0hb+1Ua5WAZTSkwxEuVn3aQNnJwVyS5eu8CikfLeVS81G8T51kMMUoKxF /oPfwCJ0zZ9bYJk27gdE/a3unZdgP4+7tdlI0TZVulL95fvGxfQFT0Urn2/7QLWZ7Nqw uQ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+qiOFhZR4jlCLuBeAREAPpPQ2xrw4kBNflTYbXXQpf8=; b=C15TR/zu8laz/8N5RVk3Yl3JT/jTPa9max3HWlCDgqtNNqaDfL3/yU42XHGzmhX21N r4FL0HSpv82GqA+/zXjDjnEUV1Ck7JfGPHO27yh//wwWo9uIaH00BvX705LE2T+Yz7iS ggLA7HsHVuY9po0zBKuS/vv2g19dY+Le3I9awWNQ1u0nWmBhAn9Iz4jyaURPGyr08i5l jsR+K7yUdfT/jDlgH1Xfph/WlxpT3sL4MPzbRyWyYEVwexH6sAQvExrUSHJbmNshHbfk DJlTLpylzSDkAPTZHKOdoT0SFyCArcWWguvvG+3X5P8TQXBlulbcW1sym63cNFvsWZEg dMgA== X-Gm-Message-State: AG10YOScEuROv3GT/6QNXsC7PsYBu/++YKL1Iiw5t4ANWx4WGI3YOV13y6gKTTXaXef/Ew== X-Received: by 10.28.187.198 with SMTP id l189mr3706001wmf.89.1453290675414; Wed, 20 Jan 2016 03:51:15 -0800 (PST) Received: from dhcp164-132.enst.fr (dhcp164-132.enst.fr. [137.194.165.132]) by smtp.gmail.com with ESMTPSA id o7sm32807102wjf.45.2016.01.20.03.51.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 03:51:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <569E4EB1.2060807@cs.tcd.ie> Date: Wed, 20 Jan 2016 12:51:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> <569E4EB1.2060807@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp-chairs@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 20 Jan 2016 11:51:22 -0000 Thanks for the comments Stephen. Crypto was not meant to be normative=E2=80=A6 We will move in its right = place: informative. further comments inline. thanks ciao L. > On 19 Jan 2016, at 15:56, Stephen Farrell = wrote: >=20 >=20 >=20 > On 19/01/16 14:50, Joel M. Halpern wrote: >> Stephen, than you for the comments. >>=20 >> With regard to the question of discussing lisp-crypto, the biggest >> concern has been creating a normative dependence on future work.=20 >=20 > Then make it informative I guess. I don't see any problem, and do > see benefits, in text along the lines of "privacy is an issue since > LISP concentrates traffic making passive monitoring of plaintext > arguably somewhat easier, people are working on [list-crypto] as > a way to deal with that." In any case, you shouldn't take anything > I've said as me wanting a normative reference to lisp-crypto, I > didn't mean to suggest that. >=20 > As that's how you've handled lisp-sec it shouldn't pose any > process issues I'd hope. >=20 > That said, I'm not a DISCUSS on this, so am non-blocking. >=20 > Cheers, > S. >=20 >=20 >> The >> charter item was to discuss threats against LISP as documented = already. >> I would like to see the crypto work covered, but it seems incorrect = to >> the charter and likely to cause a further significant delay in an >> overdue document. >>=20 >> Yours, >> Joel >>=20 >> On 1/19/16 7:07 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-lisp-threats-14: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> Thanks for doing this document. I think it's a useful part >>> of the LISP documentation set. >>>=20 >>> general: I think you underestimate the purely passive >>> threats - my point on 2.2 below was almost a DISCUSS but >>> given the WG have already adopted draft-ietf-lisp-crypto I >>> figured there's no need to try block this. I would really >>> encourage you to consider the threats that are mitigated by >>> that specification here, even if those threats weren't >>> initially considered as being that relevant to LISP (when >>> the work on LISP began I mean). If that had been done >>> already in this draft, I'd have been a YES ballot, if that >>> makes any difference;-) >>>=20 >>> - intro: I think you should add a few caveats here to say >>> that you're not covering threats due to specific >>> implementations and also that the text here captures only >>> those LISP-specific threats we know about today and that >>> more *will* be discovered as deployment continues. Good point what about change the sentences: This document does not consider all the possible uses of LISP as discussed in [RFC6830] and [RFC7215]. The document focuses on = LISP unicast, including as well LISP Interworking [RFC6832], LISP = Map- Server [RFC6833]), and LISP Map-Versioning [RFC6834].=20 in the following manner: This document does not consider all the possible uses of LISP as discussed in [RFC6830] and [RFC7215] and does not cover=20 threats due to specific implementations. The document focuses=20 on known LISP-specific threats related to LISP unicast,=20 including as well LISP Interworking [RFC6832], LISP Map- Server [RFC6833]), and LISP Map-Versioning [RFC6834].=20 Additional threats may be discovered in the future while=20 deployment continues. >>>=20 >>> - intro: you don't write about DNS here, but if some LISP >>> configuration settings use DNS names then via DNS with no >>> DNSSEC an attacker can decide to be on-path sometimes, >>> off-path other times. That (or similar) might be a nice way >>> to illustrate the scope here, while also alerting the >>> implementer to other threats that might affect their >>> implementations. >>>=20 At this stage there are no LISP configuration settings related to DNS. Hence, IMHO, there is no need to add anything. >>> - 2.1 I think it'd be valuable to say that the 2.1.x >>> sections are really just for the sake of exposition - we >>> cannot assume that all attackers fall into any neat >>> category. You do note this (more or less) in 2.1.5 but I >>> think that'd be better done in 2.1. The reason to suggest >>> this change is that being open to attackers not conforming >>> to our descriptions is important. >>>=20 The idea of 2.1.5 was to provide an example. This can be done only after=20= the different modes are explained.=20 Instead of moving text from 2.1.5 to 2.1 I would modify 2.1 in the = following manner: Attackers can be classified according to the following four = modes of operation, i.e., the temporal and spacial diversity of the = attacker. These modes are not mutually exclusive and can be used by=20 attackers in any combination. >>> - 2.2 - which section here covers purely passive monitoring? >>> All the 2.2.x seem to only cover active attacks. (I'd also >>> suggest moving the 2.2.10 text to 2.2 similarly to the >>> suggestion above for 2.1.) Good point. Similarly to 2.1 I would add the following sentence to 2.2: These categories are not mutually exclusive and can be used by=20= attackers in any combination. =20 Also I would add a new subsection numbered 2.10 and renumber the old = 2.10 as 2.11. The content of the new subsection would be: 2.2.10 Passive Monitoring Attacks =09 An attacker can use pervasive monitoring, which is a technical = attack [RFC7258], targeting information about LISP traffic that may or not be used = to mount other=20 type of attacks. =20 >>>=20 >>> - 3.8 - you probably need to note somewhere (not sure where) >>> that a bad PRNG would improve the attacker's chances in >>> various ways. I think a calculation of the probability of a >>> nonce collision (for both a good and not-good PRNG) could be >>> a useful addition. Not sure that the collision probability would be really helpful here, = but you have a point about PRNG. I suggest we change this text: If an ETR does not accept Map-Reply messages with an invalid nonce, the risk of an off-path attack = is limited given the size of the nonce (64 bits). in: Given the size of the nonce (64 bits), if best current practice = is used [RFC4086]=20 and If an ETR does not accept Map-Reply messages with an invalid = nonce,=20 the risk of an off-path attack is limited. >>>=20 >>> - 3.8, 3rd para: I would argue that this threat is a "core" >>> point to be made, as it's arguably the main LISP-specific >>> threat and ought be emphasised more, e.g. via a mention and >>> pointer in the introduction, or otherwise. >>>=20 Not sure I understand.=20 You talking about the paragraph about the attacker is a valid ETR? Why this problem is more important than others? =20 Several attacks can cause lot of damage, why this should better = highlighted? >>> - section 4 is pretty weak to be honest. I think you could >>> at least recognise that LISP, as with any mechanism that >>> concentrates traffic (between xTRs) means that passively >>> monitoring plaintext is easier than before and that there is >>> therefore value in encrypting the traffic between xTRs as is >>> proposed in draft-ietf-lisp-crypto >>>=20 I think this is covered by the last sentence of the section.=20 If an attacker knows detailed information gathered from the mappings it can use it for a lot of things, not only passive monitoring as you = suggest.=20 >>> - (nit) section 5 has a really odd sentence " The usage will >>> be designed and defined specific for the needs of the >>> specification." I've no idea what that means TBH. >>>=20 Thanks =E2=80=A6 it read really bad ;-) It is actually referred to the sentence preceding this one, but it=E2=80=99s original meaning is redundant with the sentence=20 that is right after (The exact technique still has to be designed and defined. ), hence, it can be simply dropped. Let us know if the suggested changes would answer your comments. ciao L. >>>=20 >>>=20 >>=20 From nobody Wed Jan 20 06:47:12 2016 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 B82021A8A59; Wed, 20 Jan 2016 06:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpHHYANTQTsE; Wed, 20 Jan 2016 06:47:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23FB1A8A5A; Wed, 20 Jan 2016 06:47:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9532FBE64; Wed, 20 Jan 2016 14:47:02 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38ObV8Xywenc; Wed, 20 Jan 2016 14:47:02 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68547BE8A; Wed, 20 Jan 2016 14:46:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453301216; bh=zTHYza9pygt5R78OP10X74BS+9isHLTDXlALAeDfU0s=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DyE6YYDdcfjLj9IjlnOvduCGLD1lgR2OuXwPzwsjHntqvZBTudw0CePL7HOhPWj/I lm/EUXLc8tW6oTr8NN2J2SmzB//clksu2SNgpO7/To6WVE/bNItXcMm27G81QxqAqr jYNaX7hApxFU2mMyXU9Eh8omFfjaEMq7lgHdfJWE= To: Luigi Iannone References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> <569E4EB1.2060807@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <569F9DDF.2060103@cs.tcd.ie> Date: Wed, 20 Jan 2016 14:46:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 20 Jan 2016 14:47:07 -0000 Hi Luigi, Couple of nits below but we're basically good... On 20/01/16 11:51, Luigi Iannone wrote: > Thanks for the comments Stephen. > > Crypto was not meant to be normative… We will move in its right place: informative. > > further comments inline. > > thanks ciao > > L. > > >> On 19 Jan 2016, at 15:56, Stephen Farrell wrote: >> >> >> >> On 19/01/16 14:50, Joel M. Halpern wrote: >>> Stephen, than you for the comments. >>> >>> With regard to the question of discussing lisp-crypto, the biggest >>> concern has been creating a normative dependence on future work. >> >> Then make it informative I guess. I don't see any problem, and do >> see benefits, in text along the lines of "privacy is an issue since >> LISP concentrates traffic making passive monitoring of plaintext >> arguably somewhat easier, people are working on [list-crypto] as >> a way to deal with that." In any case, you shouldn't take anything >> I've said as me wanting a normative reference to lisp-crypto, I >> didn't mean to suggest that. >> >> As that's how you've handled lisp-sec it shouldn't pose any >> process issues I'd hope. >> >> That said, I'm not a DISCUSS on this, so am non-blocking. >> >> Cheers, >> S. >> >> >>> The >>> charter item was to discuss threats against LISP as documented already. >>> I would like to see the crypto work covered, but it seems incorrect to >>> the charter and likely to cause a further significant delay in an >>> overdue document. >>> >>> Yours, >>> Joel >>> >>> On 1/19/16 7:07 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-lisp-threats-14: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> Thanks for doing this document. I think it's a useful part >>>> of the LISP documentation set. >>>> >>>> general: I think you underestimate the purely passive >>>> threats - my point on 2.2 below was almost a DISCUSS but >>>> given the WG have already adopted draft-ietf-lisp-crypto I >>>> figured there's no need to try block this. I would really >>>> encourage you to consider the threats that are mitigated by >>>> that specification here, even if those threats weren't >>>> initially considered as being that relevant to LISP (when >>>> the work on LISP began I mean). If that had been done >>>> already in this draft, I'd have been a YES ballot, if that >>>> makes any difference;-) >>>> >>>> - intro: I think you should add a few caveats here to say >>>> that you're not covering threats due to specific >>>> implementations and also that the text here captures only >>>> those LISP-specific threats we know about today and that >>>> more *will* be discovered as deployment continues. > > Good point what about change the sentences: > > This document does not consider all the possible uses of LISP as > discussed in [RFC6830] and [RFC7215]. The document focuses on LISP > unicast, including as well LISP Interworking [RFC6832], LISP Map- > Server [RFC6833]), and LISP Map-Versioning [RFC6834]. > > in the following manner: > > This document does not consider all the possible uses of LISP as > discussed in [RFC6830] and [RFC7215] and does not cover > threats due to specific implementations. The document focuses > on known LISP-specific threats related to LISP unicast, > including as well LISP Interworking [RFC6832], LISP Map- > Server [RFC6833]), and LISP Map-Versioning [RFC6834]. > Additional threats may be discovered in the future while > deployment continues. WFM > > >>>> >>>> - intro: you don't write about DNS here, but if some LISP >>>> configuration settings use DNS names then via DNS with no >>>> DNSSEC an attacker can decide to be on-path sometimes, >>>> off-path other times. That (or similar) might be a nice way >>>> to illustrate the scope here, while also alerting the >>>> implementer to other threats that might affect their >>>> implementations. >>>> > > At this stage there are no LISP configuration settings related to DNS. > Hence, IMHO, there is no need to add anything. I guess. But don't implementations probably accept DNS names in their configs? If they do then it might be an idea to use something like the above to flag that on/off-path isn't quite so clear then. > > >>>> - 2.1 I think it'd be valuable to say that the 2.1.x >>>> sections are really just for the sake of exposition - we >>>> cannot assume that all attackers fall into any neat >>>> category. You do note this (more or less) in 2.1.5 but I >>>> think that'd be better done in 2.1. The reason to suggest >>>> this change is that being open to attackers not conforming >>>> to our descriptions is important. >>>> > > The idea of 2.1.5 was to provide an example. This can be done only after > the different modes are explained. > Instead of moving text from 2.1.5 to 2.1 I would modify 2.1 in the following manner: > > Attackers can be classified according to the following four modes of > operation, i.e., the temporal and spacial diversity of the attacker. > These modes are not mutually exclusive and can be used by > attackers in any combination. That's better yes. But my point was also that an attacker doesn't have to follow our classification and will do whatever works for their attack, which may be something we've not thought about. > > > >>>> - 2.2 - which section here covers purely passive monitoring? >>>> All the 2.2.x seem to only cover active attacks. (I'd also >>>> suggest moving the 2.2.10 text to 2.2 similarly to the >>>> suggestion above for 2.1.) > > Good point. Similarly to 2.1 I would add the following sentence to 2.2: > > These categories are not mutually exclusive and can be used by > attackers in any combination. > > Also I would add a new subsection numbered 2.10 and renumber the old 2.10 as 2.11. > The content of the new subsection would be: > > 2.2.10 Passive Monitoring Attacks > > An attacker can use pervasive monitoring, which is a technical attack [RFC7258], > targeting information about LISP traffic that may or not be used to mount other > type of attacks. Sure. > >>>> >>>> - 3.8 - you probably need to note somewhere (not sure where) >>>> that a bad PRNG would improve the attacker's chances in >>>> various ways. I think a calculation of the probability of a >>>> nonce collision (for both a good and not-good PRNG) could be >>>> a useful addition. > > Not sure that the collision probability would be really helpful here, but you have a point about PRNG. > I suggest we change this text: > > If an ETR does not accept Map-Reply > messages with an invalid nonce, the risk of an off-path attack is > limited given the size of the nonce (64 bits). > > in: > > Given the size of the nonce (64 bits), if best current practice is used [RFC4086] > and If an ETR does not accept Map-Reply messages with an invalid nonce, > the risk of an off-path attack is limited. > TBH, I'm not sure what that change does. It might be better (but your call) to just say that a bad PRNG can lead to problems, so don't do that:-) > >>>> >>>> - 3.8, 3rd para: I would argue that this threat is a "core" >>>> point to be made, as it's arguably the main LISP-specific >>>> threat and ought be emphasised more, e.g. via a mention and >>>> pointer in the introduction, or otherwise. >>>> > > Not sure I understand. > You talking about the paragraph about the attacker is a valid ETR? > Why this problem is more important than others? > Several attacks can cause lot of damage, why this should better highlighted? I might well be wrong, but the overclaiming type attack seems to me to be more LISP-specific compared to others. > >>>> - section 4 is pretty weak to be honest. I think you could >>>> at least recognise that LISP, as with any mechanism that >>>> concentrates traffic (between xTRs) means that passively >>>> monitoring plaintext is easier than before and that there is >>>> therefore value in encrypting the traffic between xTRs as is >>>> proposed in draft-ietf-lisp-crypto >>>> > > I think this is covered by the last sentence of the section. > If an attacker knows detailed information gathered from the mappings > it can use it for a lot of things, not only passive monitoring as you suggest. True. > > >>>> - (nit) section 5 has a really odd sentence " The usage will >>>> be designed and defined specific for the needs of the >>>> specification." I've no idea what that means TBH. >>>> > > Thanks … it read really bad ;-) > It is actually referred to the sentence preceding this one, > but it’s original meaning is redundant with the sentence > that is right after (The exact technique still has to be designed and > defined. ), hence, it can be simply dropped. Sounds good, Cheers, S. > > > Let us know if the suggested changes would answer your comments. > > ciao > > L. > > > > > > >>>> >>>> >>> > From nobody Thu Jan 21 08:41:46 2016 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 02BB21A8759; Wed, 20 Jan 2016 11:48:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120194840.9655.16389.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 11:48:40 -0800 Archived-At: X-Mailman-Approved-At: Thu, 21 Jan 2016 08:41:46 -0800 Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, lisp-chairs@ietf.org Subject: [lisp] Alissa Cooper's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:48:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lisp-threats-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Would have been nice to see a thorough privacy analysis in Section 4. Perhaps that can be a topic for future work. From nobody Fri Jan 22 04:15:30 2016 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 756C71A1AD0 for ; Fri, 22 Jan 2016 04:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkAml7thHsyV for ; Fri, 22 Jan 2016 04:15:27 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 88FCB1A1A7D for ; Fri, 22 Jan 2016 04:15:27 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id b14so129195206wmb.1 for ; Fri, 22 Jan 2016 04:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5bUF10U8uQMWTK4rbY9qoC/rwex23REbDBCWurG6+2o=; b=ElSGSuHLu0UjMs5Lzt87Mmsuu1sXYkmGH73EZUtNgV3MecJgoeXYUMjx4BHmF9Dgd8 +1zWMzzn136XNF1Sg3CYbOmzg9gvUCV8CMAxBjypIhps8KnhuJwEf+ILptdkpFDidqjp vyIhDnNDPa1rudv9C7FjYImolnmzFk9/JN/AGQp8KGIz4nfagrEFrE2kU3LiFH4v3bPX K79jyVNf3r5QZBpKttik3kt0DXVF9qUCx6IfmISdUOl8E/TxQvutjubMRy1y1BtoIwry hD9TatxGpw9cbmCmC7Q2uDD1GfR1ZfNxQUgLyY3uR9qaiJ/aSs+yWryoSPgxjg5KLalR dzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=5bUF10U8uQMWTK4rbY9qoC/rwex23REbDBCWurG6+2o=; b=bd4MzA2raQgHCJhHiYWZL8KBAuYS+zkVs9W+sM0O2V5rG8W/Wu+lZlAacFk0+P3nEY MMujZ9+Km9RtOTijOI3IJMAn1q9WH+TQRRDGdv9Kb692asLLrbHpJNrr3wfLT4ZUbKPB 1U/LJshlx6dyBZk5ny9SZGcVBhwHwDj8mdvbd1M/VMMOjhBYeO1eOKB2VMyXbl76QAP2 KILCXhWubVJcpNkql9fEbyrjP7hjljj3SEtgqQWN9VxqwzldoTNR1CG2dH14DcOtTq6f 7VLbVFJIdJx+IeDgWyBmitQ9LpylHLmmrsYihmgIFCosJaFVqO1BUm4coHgENs0TH7O7 Ue9Q== X-Gm-Message-State: AG10YOSCB9eV1KQ36t/YuP9hJfKweL9Q+ZU5KfBzTcYq40h7TatQhIcmGYrnr6a9hXvjNQ== X-Received: by 10.28.89.195 with SMTP id n186mr3325516wmb.49.1453464926150; Fri, 22 Jan 2016 04:15:26 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:adc3:e949:4c2:4b5a? ([2001:660:330f:a4:adc3:e949:4c2:4b5a]) by smtp.gmail.com with ESMTPSA id 73sm2688981wmm.7.2016.01.22.04.15.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 04:15:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <569F9DDF.2060103@cs.tcd.ie> Date: Fri, 22 Jan 2016 13:15:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67542A5F-0A29-4216-A1EA-55D329C5D136@gigix.net> References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> <569E4EB1.2060807@cs.tcd.ie> <569F9DDF.2060103@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 22 Jan 2016 12:15:29 -0000 HI Stephen, just a couple of points inline (I trimmed the parts where we agree) > On 20 Jan 2016, at 15:46, Stephen Farrell = wrote: >=20 [snip] >>=20 >>=20 >>>>>=20 >>>>> - intro: you don't write about DNS here, but if some LISP >>>>> configuration settings use DNS names then via DNS with no >>>>> DNSSEC an attacker can decide to be on-path sometimes, >>>>> off-path other times. That (or similar) might be a nice way >>>>> to illustrate the scope here, while also alerting the >>>>> implementer to other threats that might affect their >>>>> implementations. >>>>>=20 >>=20 >> At this stage there are no LISP configuration settings related to = DNS. >> Hence, IMHO, there is no need to add anything. >=20 > I guess. But don't implementations probably accept DNS names > in their configs? If they do then it might be an idea to use > something like the above to flag that on/off-path isn't quite > so clear then. >=20 AFAICT no. There is no DNS names. It might be proposed in the future as an LCAF type, but as of today, = there is nothing like that. >>=20 >>=20 >>>>> - 2.1 I think it'd be valuable to say that the 2.1.x >>>>> sections are really just for the sake of exposition - we >>>>> cannot assume that all attackers fall into any neat >>>>> category. You do note this (more or less) in 2.1.5 but I >>>>> think that'd be better done in 2.1. The reason to suggest >>>>> this change is that being open to attackers not conforming >>>>> to our descriptions is important. >>>>>=20 >>=20 >> The idea of 2.1.5 was to provide an example. This can be done only = after=20 >> the different modes are explained.=20 >> Instead of moving text from 2.1.5 to 2.1 I would modify 2.1 in the = following manner: >>=20 >> Attackers can be classified according to the following four = modes of >> operation, i.e., the temporal and spacial diversity of the = attacker. >> These modes are not mutually exclusive and can be used by=20 >> attackers in any combination. >=20 > That's better yes. But my point was also that an attacker doesn't > have to follow our classification and will do whatever works for > their attack, which may be something we've not thought about. >=20 What about the following: Attackers can be classified according to the following four = modes of operation, i.e., the temporal and spacial diversity of the = attacker. These modes are not mutually exclusive, they can be used by=20 attackers in any combination, and other modes may be discovered=20= in the future. Does this sound better? [snip] >>=20 >>>>>=20 >>>>> - 3.8 - you probably need to note somewhere (not sure where) >>>>> that a bad PRNG would improve the attacker's chances in >>>>> various ways. I think a calculation of the probability of a >>>>> nonce collision (for both a good and not-good PRNG) could be >>>>> a useful addition. >>=20 >> Not sure that the collision probability would be really helpful here, = but you have a point about PRNG. >> I suggest we change this text: >>=20 >> If an ETR does not accept Map-Reply >> messages with an invalid nonce, the risk of an off-path attack = is >> limited given the size of the nonce (64 bits). >>=20 >> in: >>=20 >> Given the size of the nonce (64 bits), if best current practice = is used [RFC4086]=20 >> and If an ETR does not accept Map-Reply messages with an invalid = nonce,=20 >> the risk of an off-path attack is limited. >>=20 >=20 > TBH, I'm not sure what that change does. It might be better (but > your call) to just say that a bad PRNG can lead to problems, so > don't do that:-) >=20 RFC4086 is about =E2=80=9CRandomness Requirements for Security=E2=80=9D = so I guess that following those guidelines would be enough. Don=E2=80=99t you think? >>=20 >>>>>=20 >>>>> - 3.8, 3rd para: I would argue that this threat is a "core" >>>>> point to be made, as it's arguably the main LISP-specific >>>>> threat and ought be emphasised more, e.g. via a mention and >>>>> pointer in the introduction, or otherwise. >>>>>=20 >>=20 >> Not sure I understand.=20 >> You talking about the paragraph about the attacker is a valid ETR? >> Why this problem is more important than others? =20 >> Several attacks can cause lot of damage, why this should better = highlighted? >=20 > I might well be wrong, but the overclaiming type attack seems to > me to be more LISP-specific compared to others. >=20 Not really. Everything in section 3 is actually LISP-Specific.=20 Think for instance about Locator-Status-Bits (sec 3.2). [snip] Ciao L. From nobody Fri Jan 22 04:21:57 2016 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 E01231A1B0D for ; Fri, 22 Jan 2016 04:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 FgZgsptoagIQ for ; Fri, 22 Jan 2016 04:21:55 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 774CE1A1B0C for ; Fri, 22 Jan 2016 04:21:54 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id r129so211027651wmr.0 for ; Fri, 22 Jan 2016 04:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xkFxATecVbeFwm62d2VNwVQ8JBBSMSSRNcqEs1Qjwos=; b=gBdBeBmQ7HE+1PGhChSpkLMOosB5qNCOQqRC8mZ3GqktNjx4qfa9CHsIdVoA7qhRmf nZqMdOmc2Jilm05taKE7TRSPDPLWPUxzSV1piTRptgf1BjSoS0IAQFk4HRs++fprNP5F o7RmgFb1Gf1rH0XtpAKKs9hJSplBul30cavr0qXgvp7uJjJuRowKGjkHYf13aZ9DL9Id zBq6HMWJsXYpyz8x/00TKqLOswQlhK31irtLm9qlCyIpiGfZTZFsLiRmfi0h30cROZxS I8dhkcufKO2aKoqLuLvV1WBCtZoHKywCoQxbTTfQ5pTNxJbOKABrf42OVIOYC1XCJsYQ ikGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xkFxATecVbeFwm62d2VNwVQ8JBBSMSSRNcqEs1Qjwos=; b=ML8bmZVwG0djgcb5PJAgbnspj+iJmB6PrwGRZtayW1oVkoT/gQsukxp0EU75k3l38w EOD0ESixDTzA8pj/3aLPRRCVxjrlFWatLUWdtUWB015YSUIQm9MymklGBRawueCmIUuU xFuv26syGKdv19hBaJwtTvI+0UH+c41qhZ57HOjbLb7B3i9OXD0uvNT435jXo47GGhQF predK6B7BbMVHJ3vz3yk9IjVBSZmU2myjcyjpAo6U+PeyRv2DnTeA+aBTSdfx9RFp7hR YcsE+0kAl1FD/mzKEw9EWyOu+N1FvISTrbU/4rDBlfGrX+H+gJYQnMiDYAp0ZX3UdVYn FSrQ== X-Gm-Message-State: AG10YOS5zEdoXWNPo3XsBuLwI2/G4kKm/b+BpoLKWgq7N3zhRSK29e8plfXNC3914kZKMg== X-Received: by 10.28.217.83 with SMTP id q80mr3138321wmg.15.1453465313082; Fri, 22 Jan 2016 04:21:53 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:adc3:e949:4c2:4b5a? ([2001:660:330f:a4:adc3:e949:4c2:4b5a]) by smtp.gmail.com with ESMTPSA id p9sm5686192wjy.41.2016.01.22.04.21.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 04:21:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: Date: Fri, 22 Jan 2016 13:21:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A03A613-0E8C-48F6-97D5-E3D919041068@gigix.net> References: To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Proposed LISP WG Charter 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, 22 Jan 2016 12:21:57 -0000 Hi Deborah, Hereafter you can find an updated charter with additional wording on the = items you suggested. Let us know what you think. ciao Luigi %%%%%%%% LISP WG PROPOSED CHARTER = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The LISP WG has completed the first set of Experimental RFCs describing = the Locator/ID Separation Protocol (LISP). LISP supports a routing = architecture which decouples the routing locators and identifiers, thus = allowing for efficient aggregation of the routing locator space and = providing persistent identifiers in the identifier space. LISP requires = no changes to end-systems or to routers that do not directly participate = in the LISP deployment. LISP aims for an incrementally deployable = protocol. The scope of the LISP techology is recognized to range from = unicast and multicast overlays at Layer 2 as well as at Layer 3, = including NAT traversal, VPNs, and supporting mobility as a general = feature, independently of wheter it is a mobile user or a migrating VM, = hence being applicable in both Data Centers and public Internet = environments. The LISP WG is chartered to continue work on the LISP base protocol with = the main objective to develop a standard solution based on the completed = Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs = and doing the necessary enhancements to support a base set of standards = track RFCs. The group will review the current set of Working Group = documents to identify potential standards-track documents and do the = necessary enhancements to support standards-track. It is recognized that = some of the work will continue on the experimental track, though the = group is encouraged to move the documents to standards track in support = of network use, whereas the work previously was scoped to experimental = documents. Beside this main focus, the LISP WG work on the following items: =C2=B7 Multi-protocol support: Specifying the required extensions = to support multi-protocol encapsulation (e.g., L2 or NSH =E2=80=93 = Network Service Headers). Rather than developing new encapsulations the = work will aim at using existing well-established encapsulations or = emerging from other Working Grops such as NVO3 and SFC.=20 =20 =C2=B7 Alternative Mapping System Design. By extenting LISP with = new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independednt mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). =20 =C2=B7 Mobility: Some LISP deployment scenario include mobile = nodes (in mobile environments ) or Virtual Machines =E2=80=93 VMs (in = data centers), hence support needs to be provided in order to achieve = seamless connectivity. =20 =20 =C2=B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. =20 =C2=B7 Data-Plane Encryption: In some scenarios it may be = desirable to encrypt LISP encapsulated traffic. In this case, the = data-plane encryption mechanism itself and support for control-plane = security material exchange needs to be specified. =20 =C2=B7 NAT-Traversal: Support for NAT-traversal solution in = deployments where a LISP xTR is separated from correspondent xTR(s) by a = NAT (e.g., LISP mobile node). =20 =C2=B7 Models for managing the LISP protocol and deployments that = include data models, as well as allowing for programmable management = interfaces. These managament methods should be considered for both the = data-plane, control-plane, and mapping system components. =20 =20 =20 > On 20 Jan 2016, at 12:01, Luigi Iannone wrote: >=20 > This can be surely be done. >=20 > Will update the proposed charter before the end of the week. >=20 > ciao >=20 > L. >=20 >=20 >> On 19 Jan 2016, at 23:58, BRUNGARD, DEBORAH A wrote: >>=20 >> Hi Luigi, >>=20 >> Looks good - can you add a few words to scope better the three bullet = items: mobility, data-plane encryption, NAT-Traversal? >>=20 >> Thanks, >> Deborah >>=20 >>=20 >> -----Original Message----- >> From: Luigi Iannone [mailto:ggx@gigix.net]=20 >> Sent: Friday, January 15, 2016 4:15 AM >> To: BRUNGARD, DEBORAH A ; Joel Halpern Direct = >> Cc: LISP mailing list list >> Subject: Proposed LISP WG Charter >>=20 >> Hi Deborah, >>=20 >> The LISP WG had a final round of discussion (on the mailing list)=20 >> earlier this month on the new proposed charter. >>=20 >> Hereafter you can find the outcome. >> This version includes all items the WG is ready to work on. >>=20 >> thanks >>=20 >> ciao >>=20 >> Luigi >>=20 >>=20 >> %%%%%%%% LISP WG PROPOSED CHARTER = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>=20 >>=20 >> The LISP WG has completed the first set of Experimental RFCs = describing the Locator/ID Separation Protocol (LISP). LISP supports a = routing architecture which decouples the routing locators and = identifiers, thus allowing for efficient aggregation of the routing = locator space and providing persistent identifiers in the identifier = space. LISP requires no changes to end-systems or to routers that do not = directly participate in the LISP deployment. LISP aims for an = incrementally deployable protocol. The scope of the LISP techology is = recognized to range from unicast and multicast overlays at Layer 2 as = well as at Layer 3, including NAT traversal, VPNs, and supporting = mobility as a general feature, independently of wheter it is a mobile = user or a migrating VM, hence being applicable in both Data Centers and = public Internet environments. >>=20 >>=20 >> The LISP WG is chartered to continue work on the LISP base protocol = with the main objective to develop a standard solution based on the = completed Experimental RFCs and the experience gained from early = deployments. >>=20 >> This work will include reviewing the existing set of Experimental = RFCs and doing the necessary enhancements to support a base set of = standards track RFCs. The group will review the current set of Working = Group documents to identify potential standards-track documents and do = the necessary enhancements to support standards-track. It is recognized = that some of the work will continue on the experimental track, though = the group is encouraged to move the documents to standards track in = support of network use, whereas the work previously was scoped to = experimental documents. >>=20 >> Beside this main focus, the LISP WG work on the following items: >>=20 >> =C2=B7 Multi-protocol support: Specifying the required = extensions to support multi-protocol encapsulation (e.g., L2 or NSH = =E2=80=93 Network Service Headers). Rather than developing new = encapsulations the work will aim at using existing well-established = encapsulations or emerging from other Working Grops such as NVO3 and = SFC. =20 >>=20 >> =C2=B7 Alternative Mapping System Design. By extenting LISP = with new protocols support it is also necessary to develop the required = mapping function and control plane extensions to operate LISP = map-assisted networks (which might include Hierarchical Pull, = Publish/Subscribe, or Push models, independent mapping systems = interconnection, security extensions, or alternative transports of the = LISP control protocol). >>=20 >> =C2=B7 Mobility >>=20 >> =C2=B7 Multicast: Support for overlay multicast by means of = replication as well as interfacing with existing underlay multicast = support. >>=20 >> =C2=B7 Data-Plane Encryption >>=20 >> =C2=B7 NAT-Traversal >>=20 >> =C2=B7 Models for managing the LISP protocol and deployments = that include data models, as well as allowing for programmable = management interfaces. These managament methods should be considered for = both the data-plane, control-plane, and mapping system components. >>=20 >=20 From nobody Fri Jan 22 04:28:37 2016 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 EAF981A1B25; Fri, 22 Jan 2016 04:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D3BrUQ4FWAe; Fri, 22 Jan 2016 04:28:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019971A1B24; Fri, 22 Jan 2016 04:28:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD161BEA1; Fri, 22 Jan 2016 12:28:31 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5WU8tfE1Flq; Fri, 22 Jan 2016 12:28:31 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 220E5BE9A; Fri, 22 Jan 2016 12:28:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453465711; bh=xywBQUtZ3/aUnfKfTU0/As7Lj2mMY4Ef99ImYAIhBGA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dBkHYHKlVwr11gkrAAJVzMnxqbWfi6ahsSQl6YsO7h3ZTcfUdnrqoIVTJYqiaUzNi Zbb4cOn0ro2ie90R8ekL2J/i0sodD+Dvdlwrjbjv+O8/gXtriak/Z06ohAL5PFFMkN P6PyiBjgTdXWkXSfAC6IzJzu/ADDmZ8JX3DdFrlo= To: Luigi Iannone References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> <569E4EB1.2060807@cs.tcd.ie> <569F9DDF.2060103@cs.tcd.ie> <67542A5F-0A29-4216-A1EA-55D329C5D136@gigix.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56A2206E.7070305@cs.tcd.ie> Date: Fri, 22 Jan 2016 12:28:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <67542A5F-0A29-4216-A1EA-55D329C5D136@gigix.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 22 Jan 2016 12:28:36 -0000 Hi Luigi, Just on this bit, the rest is fine... On 22/01/16 12:15, Luigi Iannone wrote: > What about the following: > > > Attackers can be classified according to the following four modes of > operation, i.e., the temporal and spacial diversity of the attacker. > These modes are not mutually exclusive, they can be used by > attackers in any combination, and other modes may be discovered > in the future. There is a tendency for folks who read documents like this that set out N kinds of attack(er) to never consider that there may be an N+1th kind of attack(er). It's that that I'm suggesting we make clear. So I'd go more for: " In this document we have classified attackers according to their modes of operation, i.e., the temporal and spacial diversity of the attacker. These modes are not mutually exclusive, they can be used by attackers in any combination, and other modes may be discovered in the future. And of course attackers are not at all bound by our classification scheme, so implementers and those deploying will always need to do additional risk analysis for themselves. " But again, that's just a suggestion, feel free to take it or leave it. Cheers, S. From nobody Fri Jan 22 05:49:17 2016 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 2EE1E1A6FA0 for ; Fri, 22 Jan 2016 05:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1BhTp_S7hHn for ; Fri, 22 Jan 2016 05:49:10 -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 B34031A6F9E for ; Fri, 22 Jan 2016 05:49:08 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id n5so133055473wmn.0 for ; Fri, 22 Jan 2016 05:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+BstR1WW/XCrG/fINEmBEHcW5C7nrHutWGEnELdDSco=; b=16v1UslLPx+8x45O+3T2mme21ajLEzxkdepU0XfrOROwc8zPsynI1wzHYT1wl/DLR7 3n7vArbmJL2Pn3tRT9xFhGXzrIrZwkMtJ+f1bD6QOsmMZzl7OkDxK2/Zx1cMj/G2StCc rZAlyQVtJE9YRAUc9pXej1lrDJ7k4fvVCZPgCrJhCFzkXk70F/Rv7tk4j8EZ7wlHkrnH 4jERAx8GnLxU9qLIeF+Xgw51zVHXJhe9Ssn24eznEaJgQTQ9saJc2gZCWgmXWVjbfkUK MEGei3xLY+ix5NigQrA74K/GR9BCugsJzW6U2fe4oPtdp49m1iPa987o71YUgBdjpsC0 RqZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+BstR1WW/XCrG/fINEmBEHcW5C7nrHutWGEnELdDSco=; b=g7a+UgAOa1waxnWCJb80Qu/2c2YfTqbCSyOWI/tk/edPh2aYO2jbxZhCumDKgt03W2 Yp5RKQyc4Qu2qxCcdYXBVmuvzPThCxK7WJIVooXnW8NNEM6PW0c/kIesa38giPP0Kq6O VsmWOpFobvRSyqlnNjyyqG9LMFd2BGuDz9H+x8X5mrwqPhqp9lap6+9DcU80IGwKy0pi yAGcXTqCRrqyhOe0JSON+EdkXrTaHnMLSSiJje4cO1kDGyI0oyXCpuZP6tZFUUkCdaD2 A/qFad0rrIOkN+NONMF2oexSlJ5yoc86Eui9tIINuxMMKZHngx393en0N78w/eeihUBy sKnA== X-Gm-Message-State: AG10YOTvfmmkSU8KuMQT127sXNntLRzHwD/Ag/lBwq9cH7htNagaokVaOd28UicOH4CO7g== X-Received: by 10.194.133.164 with SMTP id pd4mr3832619wjb.133.1453470547319; Fri, 22 Jan 2016 05:49:07 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:adc3:e949:4c2:4b5a? ([2001:660:330f:a4:adc3:e949:4c2:4b5a]) by smtp.gmail.com with ESMTPSA id y188sm3028297wmy.11.2016.01.22.05.49.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 05:49:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <56A2206E.7070305@cs.tcd.ie> Date: Fri, 22 Jan 2016 14:49:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49CC4D66-83C6-4378-9DCE-77FB9F212125@gigix.net> References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> <569E4EB1.2060807@cs.tcd.ie> <569F9DDF.2060103@cs.tcd.ie> <67542A5F-0A29-4216-A1EA-55D329C5D136@gigix.net> <56A2206E.7070305@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT) 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, 22 Jan 2016 13:49:11 -0000 Hi Stephen, I am fine with the text you are proposing. Doing additional risk analysis was obvious for me, but it does not harm = to spell it out. ;-) I will include your text thanks a lot. ciao L. > On 22 Jan 2016, at 13:28, Stephen Farrell = wrote: >=20 >=20 > Hi Luigi, >=20 > Just on this bit, the rest is fine... >=20 > On 22/01/16 12:15, Luigi Iannone wrote: >> What about the following: >>=20 >>=20 >> Attackers can be classified according to the following four = modes of >> operation, i.e., the temporal and spacial diversity of the = attacker. >> These modes are not mutually exclusive, they can be used by=20 >> attackers in any combination, and other modes may be discovered=20= >> in the future. >=20 > There is a tendency for folks who read documents like this > that set out N kinds of attack(er) to never consider that > there may be an N+1th kind of attack(er). It's that that > I'm suggesting we make clear. >=20 > So I'd go more for: >=20 > " > In this document we have classified attackers according to > their modes of operation, i.e., the temporal and spacial > diversity of the attacker. These modes are not mutually > exclusive, they can be used by attackers in any combination, > and other modes may be discovered in the future. And of > course attackers are not at all bound by our classification > scheme, so implementers and those deploying will always need > to do additional risk analysis for themselves. > " >=20 > But again, that's just a suggestion, feel free to take it > or leave it. >=20 > Cheers, > S. From nobody Fri Jan 22 12:41:08 2016 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 913BC1A882C; Fri, 22 Jan 2016 12:41:05 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160122204105.10555.6347.idtracker@ietfa.amsl.com> Date: Fri, 22 Jan 2016 12:41:05 -0800 Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Last Call: (LISP EID Block) 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: Fri, 22 Jan 2016 20:41:05 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP EID Block' 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-02-05. 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 is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jan 22 12:42:19 2016 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 9037E1A883F; Fri, 22 Jan 2016 12:42:16 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160122204216.2440.87394.idtracker@ietfa.amsl.com> Date: Fri, 22 Jan 2016 12:42:16 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org Subject: [lisp] Last Call: (LISP EID Block Management Guidelines) 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: Fri, 22 Jan 2016 20:42:16 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP EID Block Management Guidelines' 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-02-05. 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 proposes a framework for the management of the LISP EID Prefix. The framework described relies on hierarchical distribution of the address space, granting temporary usage of sub-prefixes of such space to requesting organizations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jan 26 14:18:36 2016 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 377C71B322F for ; Tue, 26 Jan 2016 14:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKSbmdGVr9Tt for ; Tue, 26 Jan 2016 14:18:32 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33821B3225 for ; Tue, 26 Jan 2016 14:18:32 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0QMDqGt012584; Tue, 26 Jan 2016 17:18:32 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 20pbp347cx-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jan 2016 17:18:31 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u0QMIUnc023782; Tue, 26 Jan 2016 17:18:30 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u0QMILCW023550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jan 2016 17:18:25 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 26 Jan 2016 22:18:06 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.34]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Tue, 26 Jan 2016 17:18:06 -0500 From: "BRUNGARD, DEBORAH A" To: Luigi Iannone Thread-Topic: Proposed LISP WG Charter Thread-Index: AQHRT3Upn000fbO/oEKkNos4wAzRfZ8DeZMwgAEfDACAAzs8gIAGm99Q Date: Tue, 26 Jan 2016 22:18:05 +0000 Message-ID: References: <0A03A613-0E8C-48F6-97D5-E3D919041068@gigix.net> In-Reply-To: <0A03A613-0E8C-48F6-97D5-E3D919041068@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.80.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-26_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601260376 Archived-At: Cc: Joel Halpern Direct , LISP mailing list list Subject: Re: [lisp] Proposed LISP WG Charter 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, 26 Jan 2016 22:18:35 -0000 SGkgTHVpZ2ksDQoNCkxvb2tzIGdvb2QgLSBJIHdpbGwgc3RhcnQgdGhlIHJlY2hhcnRlcmluZyBw cm9jZXNzLg0KVGhhbmtzLA0KRGVib3JhaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBMdWlnaSBJYW5ub25lIFttYWlsdG86Z2d4QGdpZ2l4Lm5ldF0gDQpTZW50OiBGcmlk YXksIEphbnVhcnkgMjIsIDIwMTYgNzoyMiBBTQ0KVG86IEJSVU5HQVJELCBERUJPUkFIIEEgPGRi MzU0NkBhdHQuY29tPg0KQ2M6IEpvZWwgSGFscGVybiBEaXJlY3QgPGptaC5kaXJlY3RAam9lbGhh bHBlcm4uY29tPjsgTElTUCBtYWlsaW5nIGxpc3QgbGlzdCA8bGlzcEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBQcm9wb3NlZCBMSVNQIFdHIENoYXJ0ZXINCg0KSGkgRGVib3JhaCwNCg0KSGVyZWFm dGVyIHlvdSBjYW4gZmluZCBhbiB1cGRhdGVkIGNoYXJ0ZXIgd2l0aCBhZGRpdGlvbmFsIHdvcmRp bmcgb24gdGhlIGl0ZW1zIHlvdSBzdWdnZXN0ZWQuDQoNCkxldCB1cyBrbm93IHdoYXQgeW91IHRo aW5rLg0KDQpjaWFvDQoNCkx1aWdpDQoNCg0KJSUlJSUlJSUgTElTUCBXRyBQUk9QT1NFRCBDSEFS VEVSICUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ0KDQoNCg0KVGhlIExJ U1AgV0cgaGFzIGNvbXBsZXRlZCB0aGUgZmlyc3Qgc2V0IG9mIEV4cGVyaW1lbnRhbCBSRkNzIGRl c2NyaWJpbmcgdGhlIExvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbCAoTElTUCkuIExJU1Ag c3VwcG9ydHMgYSByb3V0aW5nIGFyY2hpdGVjdHVyZSB3aGljaCBkZWNvdXBsZXMgdGhlIHJvdXRp bmcgbG9jYXRvcnMgYW5kIGlkZW50aWZpZXJzLCB0aHVzIGFsbG93aW5nIGZvciBlZmZpY2llbnQg YWdncmVnYXRpb24gb2YgdGhlIHJvdXRpbmcgbG9jYXRvciBzcGFjZSBhbmQgcHJvdmlkaW5nIHBl cnNpc3RlbnQgaWRlbnRpZmllcnMgaW4gdGhlIGlkZW50aWZpZXIgc3BhY2UuIExJU1AgcmVxdWly ZXMgbm8gY2hhbmdlcyB0byBlbmQtc3lzdGVtcyBvciB0byByb3V0ZXJzIHRoYXQgZG8gbm90IGRp cmVjdGx5IHBhcnRpY2lwYXRlIGluIHRoZSBMSVNQIGRlcGxveW1lbnQuIExJU1AgYWltcyBmb3Ig YW4gaW5jcmVtZW50YWxseSBkZXBsb3lhYmxlIHByb3RvY29sLiBUaGUgc2NvcGUgb2YgdGhlIExJ U1AgdGVjaG9sb2d5IGlzIHJlY29nbml6ZWQgdG8gcmFuZ2UgZnJvbSB1bmljYXN0IGFuZCBtdWx0 aWNhc3Qgb3ZlcmxheXMgYXQgTGF5ZXIgMiBhcyB3ZWxsIGFzIGF0IExheWVyIDMsIGluY2x1ZGlu ZyBOQVQgdHJhdmVyc2FsLCBWUE5zLCAgYW5kIHN1cHBvcnRpbmcgbW9iaWxpdHkgYXMgYSBnZW5l cmFsIGZlYXR1cmUsIGluZGVwZW5kZW50bHkgb2Ygd2hldGVyIGl0IGlzIGEgbW9iaWxlIHVzZXIg b3IgYSBtaWdyYXRpbmcgVk0sIGhlbmNlIGJlaW5nIGFwcGxpY2FibGUgaW4gYm90aCBEYXRhIENl bnRlcnMgYW5kIHB1YmxpYyBJbnRlcm5ldCBlbnZpcm9ubWVudHMuDQoNCg0KVGhlIExJU1AgV0cg aXMgY2hhcnRlcmVkIHRvIGNvbnRpbnVlIHdvcmsgb24gdGhlIExJU1AgYmFzZSBwcm90b2NvbCB3 aXRoIHRoZSBtYWluIG9iamVjdGl2ZSB0byBkZXZlbG9wIGEgc3RhbmRhcmQgc29sdXRpb24gYmFz ZWQgb24gdGhlIGNvbXBsZXRlZCBFeHBlcmltZW50YWwgUkZDcyBhbmQgdGhlIGV4cGVyaWVuY2Ug Z2FpbmVkIGZyb20gZWFybHkgZGVwbG95bWVudHMuDQoNClRoaXMgd29yayB3aWxsIGluY2x1ZGUg cmV2aWV3aW5nIHRoZSBleGlzdGluZyBzZXQgb2YgRXhwZXJpbWVudGFsIFJGQ3MgYW5kIGRvaW5n IHRoZSBuZWNlc3NhcnkgZW5oYW5jZW1lbnRzIHRvIHN1cHBvcnQgYSBiYXNlIHNldCBvZiBzdGFu ZGFyZHMgdHJhY2sgUkZDcy4gVGhlIGdyb3VwIHdpbGwgcmV2aWV3IHRoZSBjdXJyZW50IHNldCBv ZiBXb3JraW5nIEdyb3VwIGRvY3VtZW50cyB0byBpZGVudGlmeSBwb3RlbnRpYWwgc3RhbmRhcmRz LXRyYWNrIGRvY3VtZW50cyBhbmQgZG8gdGhlIG5lY2Vzc2FyeSBlbmhhbmNlbWVudHMgdG8gc3Vw cG9ydCBzdGFuZGFyZHMtdHJhY2suIEl0IGlzIHJlY29nbml6ZWQgdGhhdCBzb21lIG9mIHRoZSB3 b3JrIHdpbGwgY29udGludWUgb24gdGhlIGV4cGVyaW1lbnRhbCB0cmFjaywgdGhvdWdoIHRoZSBn cm91cCBpcyBlbmNvdXJhZ2VkIHRvIG1vdmUgdGhlIGRvY3VtZW50cyB0byBzdGFuZGFyZHMgdHJh Y2sgaW4gc3VwcG9ydCBvZiBuZXR3b3JrIHVzZSwgd2hlcmVhcyB0aGUgd29yayBwcmV2aW91c2x5 IHdhcyBzY29wZWQgdG8gZXhwZXJpbWVudGFsIGRvY3VtZW50cy4NCg0KQmVzaWRlIHRoaXMgbWFp biBmb2N1cywgdGhlIExJU1AgV0cgd29yayBvbiB0aGUgZm9sbG93aW5nIGl0ZW1zOg0KDQrCtyAg ICAgICBNdWx0aS1wcm90b2NvbCBzdXBwb3J0OiBTcGVjaWZ5aW5nIHRoZSByZXF1aXJlZCBleHRl bnNpb25zIHRvIHN1cHBvcnQgbXVsdGktcHJvdG9jb2wgZW5jYXBzdWxhdGlvbiAoZS5nLiwgICBM MiBvciBOU0gg4oCTIE5ldHdvcmsgU2VydmljZSBIZWFkZXJzKS4gUmF0aGVyIHRoYW4gZGV2ZWxv cGluZyBuZXcgZW5jYXBzdWxhdGlvbnMgdGhlIHdvcmsgd2lsbCBhaW0gYXQgdXNpbmcgZXhpc3Rp bmcgd2VsbC1lc3RhYmxpc2hlZCBlbmNhcHN1bGF0aW9ucyBvciBlbWVyZ2luZyBmcm9tIG90aGVy IFdvcmtpbmcgR3JvcHMgc3VjaCBhcyAgTlZPMyBhbmQgU0ZDLiANCg0KIA0KDQrCtyAgICAgICBB bHRlcm5hdGl2ZSBNYXBwaW5nIFN5c3RlbSBEZXNpZ24uIEJ5IGV4dGVudGluZyBMSVNQIHdpdGgg IG5ldyBwcm90b2NvbHMgc3VwcG9ydCBpdCBpcyBhbHNvIG5lY2Vzc2FyeSB0byBkZXZlbG9wIHRo ZSByZXF1aXJlZCBtYXBwaW5nIGZ1bmN0aW9uIGFuZCBjb250cm9sIHBsYW5lIGV4dGVuc2lvbnMg dG8gb3BlcmF0ZSBMSVNQIG1hcC1hc3Npc3RlZCAgbmV0d29ya3MgKHdoaWNoIG1pZ2h0IGluY2x1 ZGUgSGllcmFyY2hpY2FsIFB1bGwsIFB1Ymxpc2gvU3Vic2NyaWJlLCBvciBQdXNoIG1vZGVscywg aW5kZXBlbmRlZG50IG1hcHBpbmcgc3lzdGVtcyBpbnRlcmNvbm5lY3Rpb24sIHNlY3VyaXR5IGV4 dGVuc2lvbnMsIG9yIGFsdGVybmF0aXZlIHRyYW5zcG9ydHMgb2YgdGhlIExJU1AgY29udHJvbCBw cm90b2NvbCkuDQoNCiANCg0KwrcgICAgICAgTW9iaWxpdHk6IFNvbWUgTElTUCBkZXBsb3ltZW50 IHNjZW5hcmlvIGluY2x1ZGUgbW9iaWxlIG5vZGVzIChpbiBtb2JpbGUgZW52aXJvbm1lbnRzICkg b3IgVmlydHVhbCBNYWNoaW5lcyDigJMgVk1zIChpbiBkYXRhIGNlbnRlcnMpLCBoZW5jZSBzdXBw b3J0IG5lZWRzIHRvIGJlIHByb3ZpZGVkIGluIG9yZGVyIHRvIGFjaGlldmUgc2VhbWxlc3MgY29u bmVjdGl2aXR5LiAgIA0KDQogDQoNCsK3ICAgICAgIE11bHRpY2FzdDogU3VwcG9ydCBmb3Igb3Zl cmxheSBtdWx0aWNhc3QgYnkgbWVhbnMgb2YgcmVwbGljYXRpb24gYXMgd2VsbCBhcyBpbnRlcmZh Y2luZyB3aXRoIGV4aXN0aW5nIHVuZGVybGF5IG11bHRpY2FzdCBzdXBwb3J0Lg0KDQogDQoNCsK3 ICAgICAgIERhdGEtUGxhbmUgRW5jcnlwdGlvbjogSW4gc29tZSBzY2VuYXJpb3MgaXQgbWF5IGJl IGRlc2lyYWJsZSB0byBlbmNyeXB0IExJU1AgZW5jYXBzdWxhdGVkIHRyYWZmaWMuIEluIHRoaXMg Y2FzZSwgdGhlIGRhdGEtcGxhbmUgZW5jcnlwdGlvbiBtZWNoYW5pc20gaXRzZWxmIGFuZCBzdXBw b3J0IGZvciBjb250cm9sLXBsYW5lIHNlY3VyaXR5IG1hdGVyaWFsIGV4Y2hhbmdlIG5lZWRzIHRv IGJlIHNwZWNpZmllZC4NCg0KIA0KDQrCtyAgICAgICBOQVQtVHJhdmVyc2FsOiBTdXBwb3J0IGZv ciBOQVQtdHJhdmVyc2FsIHNvbHV0aW9uIGluIGRlcGxveW1lbnRzIHdoZXJlIGEgTElTUCB4VFIg aXMgc2VwYXJhdGVkIGZyb20gY29ycmVzcG9uZGVudCB4VFIocykgYnkgYSBOQVQgKGUuZy4sIExJ U1AgbW9iaWxlIG5vZGUpLg0KDQogDQoNCsK3ICAgICAgIE1vZGVscyBmb3IgbWFuYWdpbmcgdGhl IExJU1AgcHJvdG9jb2wgYW5kIGRlcGxveW1lbnRzIHRoYXQgaW5jbHVkZSBkYXRhIG1vZGVscywg YXMgd2VsbCBhcyBhbGxvd2luZyBmb3IgcHJvZ3JhbW1hYmxlIG1hbmFnZW1lbnQgaW50ZXJmYWNl cy4gVGhlc2UgbWFuYWdhbWVudCBtZXRob2RzIHNob3VsZCBiZSBjb25zaWRlcmVkIGZvciBib3Ro IHRoZSBkYXRhLXBsYW5lLCBjb250cm9sLXBsYW5lLCBhbmQgbWFwcGluZyBzeXN0ZW0gY29tcG9u ZW50cy4NCg0KIA0KDQogDQoNCiANCg0KDQoNCj4gT24gMjAgSmFuIDIwMTYsIGF0IDEyOjAxLCBM dWlnaSBJYW5ub25lIDxnZ3hAZ2lnaXgubmV0PiB3cm90ZToNCj4gDQo+IFRoaXMgY2FuIGJlIHN1 cmVseSBiZSBkb25lLg0KPiANCj4gV2lsbCB1cGRhdGUgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYmVm b3JlIHRoZSBlbmQgb2YgdGhlIHdlZWsuDQo+IA0KPiBjaWFvDQo+IA0KPiBMLg0KPiANCj4gDQo+ PiBPbiAxOSBKYW4gMjAxNiwgYXQgMjM6NTgsIEJSVU5HQVJELCBERUJPUkFIIEEgPGRiMzU0NkBh dHQuY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgTHVpZ2ksDQo+PiANCj4+IExvb2tzIGdvb2QgLSBj YW4geW91IGFkZCBhIGZldyB3b3JkcyB0byBzY29wZSBiZXR0ZXIgdGhlIHRocmVlIGJ1bGxldCBp dGVtczogbW9iaWxpdHksIGRhdGEtcGxhbmUgZW5jcnlwdGlvbiwgTkFULVRyYXZlcnNhbD8NCj4+ IA0KPj4gVGhhbmtzLA0KPj4gRGVib3JhaA0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBMdWlnaSBJYW5ub25lIFttYWlsdG86Z2d4QGdpZ2l4Lm5ldF0g DQo+PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTUsIDIwMTYgNDoxNSBBTQ0KPj4gVG86IEJSVU5H QVJELCBERUJPUkFIIEEgPGRiMzU0NkBhdHQuY29tPjsgSm9lbCBIYWxwZXJuIERpcmVjdCA8am1o LmRpcmVjdEBqb2VsaGFscGVybi5jb20+DQo+PiBDYzogTElTUCBtYWlsaW5nIGxpc3QgbGlzdCA8 bGlzcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFByb3Bvc2VkIExJU1AgV0cgQ2hhcnRlcg0KPj4g DQo+PiBIaSBEZWJvcmFoLA0KPj4gDQo+PiBUaGUgTElTUCBXRyBoYWQgYSBmaW5hbCByb3VuZCBv ZiBkaXNjdXNzaW9uIChvbiB0aGUgbWFpbGluZyBsaXN0KSANCj4+IGVhcmxpZXIgdGhpcyBtb250 aCBvbiB0aGUgbmV3IHByb3Bvc2VkIGNoYXJ0ZXIuDQo+PiANCj4+IEhlcmVhZnRlciB5b3UgY2Fu IGZpbmQgdGhlIG91dGNvbWUuDQo+PiBUaGlzIHZlcnNpb24gaW5jbHVkZXMgYWxsIGl0ZW1zIHRo ZSBXRyBpcyByZWFkeSB0byB3b3JrIG9uLg0KPj4gDQo+PiB0aGFua3MNCj4+IA0KPj4gY2lhbw0K Pj4gDQo+PiBMdWlnaQ0KPj4gDQo+PiANCj4+ICUlJSUlJSUlIExJU1AgV0cgUFJPUE9TRUQgQ0hB UlRFUiAlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUNCj4+IA0KPj4gDQo+ PiBUaGUgTElTUCBXRyBoYXMgY29tcGxldGVkIHRoZSBmaXJzdCBzZXQgb2YgRXhwZXJpbWVudGFs IFJGQ3MgZGVzY3JpYmluZyB0aGUgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQ KS4gTElTUCBzdXBwb3J0cyBhIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIHdoaWNoIGRlY291cGxlcyB0 aGUgcm91dGluZyBsb2NhdG9ycyBhbmQgaWRlbnRpZmllcnMsIHRodXMgYWxsb3dpbmcgZm9yIGVm ZmljaWVudCBhZ2dyZWdhdGlvbiBvZiB0aGUgcm91dGluZyBsb2NhdG9yIHNwYWNlIGFuZCBwcm92 aWRpbmcgcGVyc2lzdGVudCBpZGVudGlmaWVycyBpbiB0aGUgaWRlbnRpZmllciBzcGFjZS4gTElT UCByZXF1aXJlcyBubyBjaGFuZ2VzIHRvIGVuZC1zeXN0ZW1zIG9yIHRvIHJvdXRlcnMgdGhhdCBk byBub3QgZGlyZWN0bHkgcGFydGljaXBhdGUgaW4gdGhlIExJU1AgZGVwbG95bWVudC4gTElTUCBh aW1zIGZvciBhbiBpbmNyZW1lbnRhbGx5IGRlcGxveWFibGUgcHJvdG9jb2wuIFRoZSBzY29wZSBv ZiB0aGUgTElTUCB0ZWNob2xvZ3kgaXMgcmVjb2duaXplZCB0byByYW5nZSBmcm9tIHVuaWNhc3Qg YW5kIG11bHRpY2FzdCBvdmVybGF5cyBhdCBMYXllciAyIGFzIHdlbGwgYXMgYXQgTGF5ZXIgMywg aW5jbHVkaW5nIE5BVCB0cmF2ZXJzYWwsIFZQTnMsICBhbmQgc3VwcG9ydGluZyBtb2JpbGl0eSBh cyBhIGdlbmVyYWwgZmVhdHVyZSwgaW5kZXBlbmRlbnRseSBvZiB3aGV0ZXIgaXQgaXMgYSBtb2Jp bGUgdXNlciBvciBhIG1pZ3JhdGluZyBWTSwgaGVuY2UgYmVpbmcgYXBwbGljYWJsZSBpbiBib3Ro IERhdGEgQ2VudGVycyBhbmQgcHVibGljIEludGVybmV0IGVudmlyb25tZW50cy4NCj4+IA0KPj4g DQo+PiBUaGUgTElTUCBXRyBpcyBjaGFydGVyZWQgdG8gY29udGludWUgd29yayBvbiB0aGUgTElT UCBiYXNlIHByb3RvY29sIHdpdGggdGhlIG1haW4gb2JqZWN0aXZlIHRvIGRldmVsb3AgYSBzdGFu ZGFyZCBzb2x1dGlvbiBiYXNlZCBvbiB0aGUgY29tcGxldGVkIEV4cGVyaW1lbnRhbCBSRkNzIGFu ZCB0aGUgZXhwZXJpZW5jZSBnYWluZWQgZnJvbSBlYXJseSBkZXBsb3ltZW50cy4NCj4+IA0KPj4g VGhpcyB3b3JrIHdpbGwgaW5jbHVkZSByZXZpZXdpbmcgdGhlIGV4aXN0aW5nIHNldCBvZiBFeHBl cmltZW50YWwgUkZDcyBhbmQgZG9pbmcgdGhlIG5lY2Vzc2FyeSBlbmhhbmNlbWVudHMgdG8gc3Vw cG9ydCBhIGJhc2Ugc2V0IG9mIHN0YW5kYXJkcyB0cmFjayBSRkNzLiBUaGUgZ3JvdXAgd2lsbCBy ZXZpZXcgdGhlIGN1cnJlbnQgc2V0IG9mIFdvcmtpbmcgR3JvdXAgZG9jdW1lbnRzIHRvIGlkZW50 aWZ5IHBvdGVudGlhbCBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnRzIGFuZCBkbyB0aGUgbmVjZXNz YXJ5IGVuaGFuY2VtZW50cyB0byBzdXBwb3J0IHN0YW5kYXJkcy10cmFjay4gSXQgaXMgcmVjb2du aXplZCB0aGF0IHNvbWUgb2YgdGhlIHdvcmsgd2lsbCBjb250aW51ZSBvbiB0aGUgZXhwZXJpbWVu dGFsIHRyYWNrLCB0aG91Z2ggdGhlIGdyb3VwIGlzIGVuY291cmFnZWQgdG8gbW92ZSB0aGUgZG9j dW1lbnRzIHRvIHN0YW5kYXJkcyB0cmFjayBpbiBzdXBwb3J0IG9mIG5ldHdvcmsgdXNlLCB3aGVy ZWFzIHRoZSB3b3JrIHByZXZpb3VzbHkgd2FzIHNjb3BlZCB0byBleHBlcmltZW50YWwgZG9jdW1l bnRzLg0KPj4gDQo+PiBCZXNpZGUgdGhpcyBtYWluIGZvY3VzLCB0aGUgTElTUCBXRyB3b3JrIG9u IHRoZSBmb2xsb3dpbmcgaXRlbXM6DQo+PiANCj4+IMK3ICAgICAgIE11bHRpLXByb3RvY29sIHN1 cHBvcnQ6IFNwZWNpZnlpbmcgdGhlIHJlcXVpcmVkIGV4dGVuc2lvbnMgdG8gc3VwcG9ydCBtdWx0 aS1wcm90b2NvbCBlbmNhcHN1bGF0aW9uIChlLmcuLCAgIEwyIG9yIE5TSCDigJMgTmV0d29yayBT ZXJ2aWNlIEhlYWRlcnMpLiBSYXRoZXIgdGhhbiBkZXZlbG9waW5nIG5ldyBlbmNhcHN1bGF0aW9u cyB0aGUgd29yayB3aWxsIGFpbSBhdCB1c2luZyBleGlzdGluZyB3ZWxsLWVzdGFibGlzaGVkIGVu Y2Fwc3VsYXRpb25zIG9yIGVtZXJnaW5nIGZyb20gb3RoZXIgV29ya2luZyBHcm9wcyBzdWNoIGFz ICBOVk8zIGFuZCBTRkMuICANCj4+IA0KPj4gwrcgICAgICAgQWx0ZXJuYXRpdmUgTWFwcGluZyBT eXN0ZW0gRGVzaWduLiBCeSBleHRlbnRpbmcgTElTUCB3aXRoICBuZXcgcHJvdG9jb2xzIHN1cHBv cnQgaXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gZGV2ZWxvcCB0aGUgcmVxdWlyZWQgbWFwcGluZyBm dW5jdGlvbiBhbmQgY29udHJvbCBwbGFuZSBleHRlbnNpb25zIHRvIG9wZXJhdGUgTElTUCBtYXAt YXNzaXN0ZWQgIG5ldHdvcmtzICh3aGljaCBtaWdodCBpbmNsdWRlIEhpZXJhcmNoaWNhbCBQdWxs LCBQdWJsaXNoL1N1YnNjcmliZSwgb3IgUHVzaCBtb2RlbHMsIGluZGVwZW5kZW50IG1hcHBpbmcg c3lzdGVtcyBpbnRlcmNvbm5lY3Rpb24sIHNlY3VyaXR5IGV4dGVuc2lvbnMsIG9yIGFsdGVybmF0 aXZlIHRyYW5zcG9ydHMgb2YgdGhlIExJU1AgY29udHJvbCBwcm90b2NvbCkuDQo+PiANCj4+IMK3 ICAgICAgIE1vYmlsaXR5DQo+PiANCj4+IMK3ICAgICAgIE11bHRpY2FzdDogU3VwcG9ydCBmb3Ig b3ZlcmxheSBtdWx0aWNhc3QgYnkgbWVhbnMgb2YgcmVwbGljYXRpb24gYXMgd2VsbCBhcyBpbnRl cmZhY2luZyB3aXRoIGV4aXN0aW5nIHVuZGVybGF5IG11bHRpY2FzdCBzdXBwb3J0Lg0KPj4gDQo+ PiDCtyAgICAgICBEYXRhLVBsYW5lIEVuY3J5cHRpb24NCj4+IA0KPj4gwrcgICAgICAgTkFULVRy YXZlcnNhbA0KPj4gDQo+PiDCtyAgICAgICBNb2RlbHMgZm9yIG1hbmFnaW5nIHRoZSBMSVNQIHBy b3RvY29sIGFuZCBkZXBsb3ltZW50cyB0aGF0IGluY2x1ZGUgZGF0YSBtb2RlbHMsIGFzIHdlbGwg YXMgYWxsb3dpbmcgZm9yIHByb2dyYW1tYWJsZSBtYW5hZ2VtZW50IGludGVyZmFjZXMuIFRoZXNl IG1hbmFnYW1lbnQgbWV0aG9kcyBzaG91bGQgYmUgY29uc2lkZXJlZCBmb3IgYm90aCB0aGUgZGF0 YS1wbGFuZSwgY29udHJvbC1wbGFuZSwgYW5kIG1hcHBpbmcgc3lzdGVtIGNvbXBvbmVudHMuDQo+ PiANCj4gDQoNCg== From nobody Fri Jan 29 02:56:54 2016 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 529111B2C79; Fri, 29 Jan 2016 02:56:53 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129105653.27593.80809.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 02:56:53 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-15.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, 29 Jan 2016 10:56:53 -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-15.txt Pages : 22 Date : 2016-01-29 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-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-threats-15 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 Sun Jan 31 23:08:14 2016 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 2D7AB1B2D57; Sun, 31 Jan 2016 23:08:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201070814.928.30984.idtracker@ietfa.amsl.com> Date: Sun, 31 Jan 2016 23:08:14 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Joel Jaeggli's No Objection on charter-ietf-lisp-03-00: (with COMMENT) 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, 01 Feb 2016 07:08:14 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am sympathetic to the idea that we should curating the existing work with an eye towards what worked and what didn't. I would personally like to see the new work items more fleshed out with respect to what the deliverables are supposed to look like, mostly the mobile and multicast items need to be fleshed out I think.