From hadi@mojatatu.com Sun Jan 5 08:54:43 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4168C1AEF82 for ; Sun, 5 Jan 2014 08:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 ncsGFHKHh-cn for ; Sun, 5 Jan 2014 08:54:42 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id C9C3B1AEF83 for ; Sun, 5 Jan 2014 08:54:41 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jz11so8600927veb.25 for ; Sun, 05 Jan 2014 08:54:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=yYrdX8oYHF1Uji6Aca1aon1BkvxXKnlbhiZJswz/nSQ=; b=CwJOceZa9kzC2xfPOCy0ajZz78XIGS+VHRODYAf+Kn45E60cA1yKYqC8R+jYWB0YVE f1TRwNGDIHPfjnIw5xz176uRZOvAP9+Ps+Cp9RPUzC0Jqfn8BwNCuPIPRGZBIu7GU/wN G+e/xqO71pVrjWcPNMIEVMXOUdvatObcCMW4qhfOTwn5XZYG0sYdh8gf4Jp/cu0WKBU4 X64hZ6TgYOPKm5uDI4qo4pcSNj7XgJoJGY6ETUffaSENdTV4ZcPwXuKOTTBGyItz2dkn vPrE8+ALTpStXxR3BOJwITZbIhAf/N7FPsv7mZqC5O4T5yRkEpNW9uWCprB2cIbu/70M vXPg== X-Gm-Message-State: ALoCoQmpW2rX9J9oyYY3PQt3DgkS68gWFH41i3VBiucgDugx8IwJmxxqMKsjqEwxIwLal1IrkTHB X-Received: by 10.58.57.194 with SMTP id k2mr20809283veq.0.1388940873573; Sun, 05 Jan 2014 08:54:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Sun, 5 Jan 2014 08:54:13 -0800 (PST) In-Reply-To: <20140105165035.5358.56894.idtracker@ietfa.amsl.com> References: <20140105165035.5358.56894.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Sun, 5 Jan 2014 11:54:13 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] Fwd: New Version Notification for draft-jhs-forces-protoextenstion-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 16:54:43 -0000 I was hoping to complete validating the implementation before publishing. Although the draft conforms to the implementation there are still a few annotated "XXX" in the text that came up while implementing. Please help reviewing and providing feedback. As discussed in Vancouver, I'd like to push this to be a WG item once we get feedback and fix the text. cheers, jamal ---------- Forwarded message ---------- From: Date: Sun, Jan 5, 2014 at 11:50 AM Subject: New Version Notification for draft-jhs-forces-protoextenstion-02.txt To: Jamal Hadi Salim A new version of I-D, draft-jhs-forces-protoextenstion-02.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Name: draft-jhs-forces-protoextenstion Revision: 02 Title: ForCES Protocol Extensions Document date: 2014-01-05 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-jhs-forces-protoextenstion-02.txt Status: https://datatracker.ietf.org/doc/draft-jhs-forces-protoextenstion/ Htmlized: http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-jhs-forces-protoextenstion-02 Abstract: Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes extensions to the ForCES Protocol Specification[RFC 5810] semantics to achieve that end goal. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From hadi@mojatatu.com Mon Jan 13 04:05:53 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921591AE134 for ; Mon, 13 Jan 2014 04:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 VZN__D67PQ7E for ; Mon, 13 Jan 2014 04:05:52 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id E7F6C1AE115 for ; Mon, 13 Jan 2014 04:05:51 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id q16so3048998vbe.35 for ; Mon, 13 Jan 2014 04:05:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=N1ZEGQzCbaZXiuMw1zydd2DreiZ/OKxaUaW1Bv3kvwU=; b=gsOtDS9ToOnJUNJUImOmi8D7sSANFl44L/W9Q58L9ivdSjP211y7lU+JfDONM51ehX EtbGDOhWszU15J0uhgmCJVn0RbDwte/PFn18hK0vCwenRa2EGmCvZpXLor42fbwK6nuy gkwBAUCQ0g4NNyfvnnW+AfODfxNm9WBarC0bXjsWNBPSd4HPXroGVtz7ynYX1jTbKDZf eE4ybfYUc/j7BhvTIsH9Zb+N4keSUk+f4zmNzcKITSUS81hIdrLrTC1i1+IFNsndRoKV GjBkHd35nj7DaBHA2sXnfds2rPpjnjAn6gql9JmzbF0Al1tLifgvh4qK3ck63FCFDhIU dRpg== X-Gm-Message-State: ALoCoQkgbpp1eQ1zZww0cYizgk42HH7GwMxAvJce9zrataPSLxBJLpm2jerbffMmArxVRfOkaYr2 X-Received: by 10.58.54.116 with SMTP id i20mr2150vep.67.1389614740698; Mon, 13 Jan 2014 04:05:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Mon, 13 Jan 2014 04:05:20 -0800 (PST) From: Jamal Hadi Salim Date: Mon, 13 Jan 2014 07:05:20 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] Exception ID definition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:05:53 -0000 While reviewing inter-FE ID (it is about to expire), we noted that we would need to transfer about Exception data. Therefore we would need a TLV type for exception IDs defined. Exception IDs are first used in the LFB lib. Unfortunately we missed to reflect it in that doc's IANA section. So it is an error in that doc. What is the best way to fix this? Would the new protocol extension be the right place to ask for such a definition? cheers, jamal From adrian@olddog.co.uk Mon Jan 13 04:21:51 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEBC1AE14F for ; Mon, 13 Jan 2014 04:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 7ZVKQ-V6zMaG for ; Mon, 13 Jan 2014 04:21:50 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 37D241AE14D for ; Mon, 13 Jan 2014 04:21:50 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0DCLbHO025195; Mon, 13 Jan 2014 12:21:38 GMT Received: from 950129200 ([147.67.4.98]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0DCLZql025107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jan 2014 12:21:36 GMT From: "Adrian Farrel" To: "'Jamal Hadi Salim'" , References: In-Reply-To: Date: Mon, 13 Jan 2014 12:21:37 -0000 Message-ID: <025901cf105a$02e61d50$08b257f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIqywgEXUsQFAi/35YCYdcqL44Sw5nLHS+w Content-Language: en-gb X-TM-AS-MML: No Subject: Re: [forces] Exception ID definition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:21:51 -0000 Hi Jamal, Yes, you can't fix this with an Errata Report. You need a new RFC. Either a revision of an existing RFC, or a new mini-RFC. Or fix it using the inter-FE ID (least preferred). Cheers, Adrian > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: 13 January 2014 12:05 > To: forces@ietf.org > Cc: Adrian Farrel > Subject: Exception ID definition > > While reviewing inter-FE ID (it is about to expire), we noted that > we would need to transfer about Exception data. Therefore > we would need a TLV type for exception IDs defined. > Exception IDs are first used in the LFB lib. Unfortunately we missed > to reflect it in that doc's IANA section. So it is an error in that doc. > > What is the best way to fix this? > Would the new protocol extension be the right place to ask for such > a definition? > > cheers, > jamal From hadi@mojatatu.com Mon Jan 13 04:25:34 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72D11AE152 for ; Mon, 13 Jan 2014 04:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 OF57rgIQ5Hfj for ; Mon, 13 Jan 2014 04:25:33 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id AC6431AE151 for ; Mon, 13 Jan 2014 04:25:33 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id m10so2070312vbh.4 for ; Mon, 13 Jan 2014 04:25:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=38QHv+nRisDrqr9iY0FohF8gJ/EiGgVszAkoQ66fEuE=; b=ZB5TqAZb+2C0cDW2YMDqwYwAXM32PE5TbmO45ZlcQz0zmDbsHzLETRJ2jVFT8BPNrU u97E57FrwF4KNl7nEC3n8p6yHcC/lKzt+e+SW9X3K5pkee09Hj+46d3PTMEUB/7yCJNq YppggWu91KywCJtTVGs7TZRwwAjmL98KLil6+gXIhokc6k1PPhD1onpvxbpVag1XSuvb yZoHf6nBnnWyriuX5u8RwPEPTOe8C28K73CdrAvn0cQiW4YOBeuOQqgOHHSZiD2dD4Sh S012NqNLzvBGdHpcJ/22myLAijBpnJFdt3ytvGZyYwQ/qQBBcqyXFXFzxdj6qBdCSOMl QEzw== X-Gm-Message-State: ALoCoQnRJgEmhCgICT0i++B1YrZ7tKDBpqIpDt/3Y0CN1MNS6xszeK2PZglzryKXrupF6GZndom8 X-Received: by 10.58.219.1 with SMTP id pk1mr1355182vec.49.1389615922518; Mon, 13 Jan 2014 04:25:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Mon, 13 Jan 2014 04:25:02 -0800 (PST) In-Reply-To: <025901cf105a$02e61d50$08b257f0$@olddog.co.uk> References: <025901cf105a$02e61d50$08b257f0$@olddog.co.uk> From: Jamal Hadi Salim Date: Mon, 13 Jan 2014 07:25:02 -0500 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] Exception ID definition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:25:35 -0000 Adrian, What about the protocol extension document (since this is a protocol definition extension)? cheers, jamal On Mon, Jan 13, 2014 at 7:21 AM, Adrian Farrel wrote: > Hi Jamal, > Yes, you can't fix this with an Errata Report. You need a new RFC. > Either a revision of an existing RFC, or a new mini-RFC. Or fix it using the > inter-FE ID (least preferred). > > Cheers, > Adrian > >> -----Original Message----- >> From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] >> Sent: 13 January 2014 12:05 >> To: forces@ietf.org >> Cc: Adrian Farrel >> Subject: Exception ID definition >> >> While reviewing inter-FE ID (it is about to expire), we noted that >> we would need to transfer about Exception data. Therefore >> we would need a TLV type for exception IDs defined. >> Exception IDs are first used in the LFB lib. Unfortunately we missed >> to reflect it in that doc's IANA section. So it is an error in that doc. >> >> What is the best way to fix this? >> Would the new protocol extension be the right place to ask for such >> a definition? >> >> cheers, >> jamal > From ehalep@gmail.com Mon Jan 13 05:32:27 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E01AE077 for ; Mon, 13 Jan 2014 05:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErTl2cWAzEgF for ; Mon, 13 Jan 2014 05:32:25 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF11AE074 for ; Mon, 13 Jan 2014 05:32:24 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id h10so3280106eak.2 for ; Mon, 13 Jan 2014 05:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=TCn8uSafEi8+4QIOHHexjRL0lOIYbhBsbNeTSKfHDHc=; b=hkC4+IEFp/UQoeCm7aV+hUFKOgi+EX8f1cJzQRI9Ct/sWIY8VK+85eXxfnSOU3S+Jz m/VVCan7jkr+GiMrrGhvmkip7qWbYEz7qmGzhVuLaZXCLUvFlAt1xLK8v+LE+CiHMoDp DSb2T8vpPjd9kLnrfYsOxpdToG92ab/xj1f9K/v8vYIV9CClPg2TDYOBIhIIopz7iMup 8jUGfckzSwMQzGhwSy1GpKBC3xle2qIm4occxKhh9Ly6W9mHtQmSAY2uNnagkjpDW7Yd PoTbfKO+GLT4eI7w+vXFySgRgrzF5JDlJEoKjfqUs1SKtrifSQH9ych+8r9Wz2bVvc9j ZIEg== X-Received: by 10.14.207.194 with SMTP id n42mr28049495eeo.76.1389619933568; Mon, 13 Jan 2014 05:32:13 -0800 (PST) Received: from EhalepXPS (ppp141237111151.access.hol.gr. [141.237.111.151]) by mx.google.com with ESMTPSA id z46sm1701737een.1.2014.01.13.05.32.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jan 2014 05:32:12 -0800 (PST) From: "Haleplidis Evangelos" To: Date: Mon, 13 Jan 2014 15:32:09 +0200 Message-ID: <00cc01cf1063$dd346940$979d3bc0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01CF1074.A0BD3940" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8QY9uyz9x56TzgTOCUYM+dlC31RQ== Content-language: el Subject: [forces] Protocol extension comments X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:32:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01CF1074.A0BD3940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings Jamal, I have the following comments for the http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-02. 1. There is already a wg item with the same name. http://tools.ietf.org/html/draft-ietf-forces-protoextension-00 http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-02 (there is a typo in this name, "extenstion") You updated the non-wg. These comments are for the updated one. 2. Table-range: I would suggest you add what happens when someone does a table-range get/set/del but the component is NOT a table. Which error code should it return? Should we create a new one, e.g. E_COMPONENT_NOT_A_TABLE? 3. Table-range: Just a suggestion. Show the Table-Range-TLV. Something like the following: +---------------------+---------------------+ | Type | Length | +---------------------+---------------------+ | Start Index | +---------------------+---------------------+ | End Index | +---------------------+---------------------+ 4. Extended Result TLV: This requires a necessary change to the FEPO. Is it possible to include this change to the 1.1 required by the CEHA document, in order not to do too many versions? 5. There are some typo's as well inside the document (e.g. "upto", or in some bullet points you have half sentences starting with capital, the rest with non-capital). Regards, Evangelos Haleplidis. ------=_NextPart_000_00CD_01CF1074.A0BD3940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings Jamal,

 

I have the following comments = for the h= ttp://tools.ietf.org/html/draft-jhs-forces-protoextenstion-02.

 

1. There is already a wg item with the same = name.

<= span = lang=3DEN-US>http://tools.ietf.org/html/draft-ietf-forces-protoextension-= 00

<= span = lang=3DEN-US>http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-= 02 (there is a typo in this name, = "extenstion") You updated the non-wg. These comments = are for the updated one.

 

2. Table-range:

I would suggest you add what = happens when someone does a table-range get/set/del but the component is = NOT a table.

Which error code should it return? Should we create a new = one, e.g. E_COMPONENT_NOT_A_TABLE?

 

3. = Table-range:

Just a suggestion. Show the Table-Range-TLV. Something like = the following:

+---------------------+---------------------+

| =       Type     &nb= sp;    |       = Length        = |

+---------------------+---------------------+

|          = ;      Start = Index           &n= bsp;    |

+---------------------+---------------------+

|          = ;       End = Index           &n= bsp;     |

+---------------------+---------------------+

 

4. Extended Result TLV:

This requires a necessary change = to the FEPO.

Is it possible to include this change to the 1.1 required = by the CEHA document, in order not to do too many = versions?

 

5. There are some typo's as well inside the document (e.g. = "upto", or in some bullet points you have half sentences = starting with capital, the rest with = non-capital).

 

Regards,

Evangelos Haleplidis.

          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; 

------=_NextPart_000_00CD_01CF1074.A0BD3940-- From hadi@mojatatu.com Mon Jan 13 05:35:51 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C91AE077 for ; Mon, 13 Jan 2014 05:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 jyXr-Q48gpWk for ; Mon, 13 Jan 2014 05:35:49 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id C5D4B1AE074 for ; Mon, 13 Jan 2014 05:35:49 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id m10so2112881vbh.4 for ; Mon, 13 Jan 2014 05:35:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CiDwTDEylc3hOKgjnipbr/B+LeaZ92lmn3rSAYlfS1Q=; b=Ej3n/n/y8qNPI0nL9eAdyjDyoKx0vApkfEc1QS/MR9YH/tFTkmK+4Ln+F/SzlydjBv 3Z2yXsOQf6G8swBLCBc7OBaMtkQpLlO0+RxlhpkRADrzu7OdXp5PfkXmf7NG21tHBtVz OM5zIEcFT7FyAVxJfcNUTwbt33EzbveIk6lMeAp07Bhj41hAQ77FHJk1/Z9GCyI2QhW1 f0rhR5I39xMavjkB2I8Qv5NAf4zZOVZTsxsj899AzPSBJguaTrPdPUcrHATT8iXaaaqf TwGDzqVy41dlEuPSJkMZ1r1djSlq2AWQeG5ONpTf+rE2CNiQYJp7QRdTHmafLJv1wMSj QCMw== X-Gm-Message-State: ALoCoQkPwWk4s9TxQFXnbQzoga36yIqvOrrKyBgwEmRraX2hYI6iPnZ0bdlIjcl8kjHBCNNOcQPB X-Received: by 10.58.118.36 with SMTP id kj4mr17928953veb.2.1389620138668; Mon, 13 Jan 2014 05:35:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Mon, 13 Jan 2014 05:35:18 -0800 (PST) In-Reply-To: <000101cee323$93957850$bac068f0$@com> References: <000101cee323$93957850$bac068f0$@com> From: Jamal Hadi Salim Date: Mon, 13 Jan 2014 08:35:18 -0500 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-packet-parallelization-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:35:51 -0000 As per discussion in Vancouver - the chairs believe there is sufficient interest in this document for it to become a WG item. I did promise to do another review but priorities havent bubbled up yet. My gut feeling is to say please go ahead and resubmit as a WG item unless there is objection to it. cheers, jamal On Sat, Nov 16, 2013 at 6:28 PM, Haleplidis Evangelos wrote: > Greetings to the list, > > We have just updated the parallelization draft after the decisions made in the Vancouver meeting. > > As we said in the meeting we believe this document is very stable and we would like to ask this document to be accepted as a wg item. > > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Sunday, November 17, 2013 1:25 AM >> To: Joel Halpern; Evangelos Haleplidis >> Subject: New Version Notification for draft-haleplidis-forces-packet- >> parallelization-04.txt >> >> >> A new version of I-D, draft-haleplidis-forces-packet-parallelization- >> 04.txt >> has been successfully submitted by Evangelos Haleplidis and posted to >> the IETF repository. >> >> Filename: draft-haleplidis-forces-packet-parallelization >> Revision: 04 >> Title: ForCES Packet Parallelization >> Creation date: 2013-11-16 >> Group: Individual Submission >> Number of pages: 22 >> URL: http://www.ietf.org/internet-drafts/draft-haleplidis-forces-packet-parallelization-04.txt >> Status: http://datatracker.ietf.org/doc/draft-haleplidis-forces-packet-parallelization >> Htmlized: http://tools.ietf.org/html/draft-haleplidis-forces-packet-parallelization-04 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-haleplidis-forces-packet-parallelization-04 >> >> Abstract: >> Forwarding and Control Element Separation (ForCES) defines an >> architectural framework and associated protocols to standardize >> information exchange between the control plane and the forwarding >> plane in a ForCES Network Element (ForCES NE). RFC5812 has defined >> the ForCES Model provides a formal way to represent the >> capabilities, >> state, and configuration of forwarding elements within the context >> of >> the ForCES protocol, so that control elements (CEs) can control the >> FEs accordingly. More specifically, the model describes the logical >> functions that are present in an FE, what capabilities these >> functions support, and how these functions are or can be >> interconnected. >> >> Many network devices support parallel packet processing. This >> document describes how ForCES can model a network device's >> parallelization datapath. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From adrian@olddog.co.uk Mon Jan 13 05:57:20 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E341AE15B for ; Mon, 13 Jan 2014 05:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 gir5fC7Lsh-a for ; Mon, 13 Jan 2014 05:57:19 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B27F61AE06C for ; Mon, 13 Jan 2014 05:57:18 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0DDv5Bd008123; Mon, 13 Jan 2014 13:57:06 GMT Received: from 950129200 ([147.67.4.98]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0DDv44B008106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jan 2014 13:57:05 GMT From: "Adrian Farrel" To: "'Jamal Hadi Salim'" References: <025901cf105a$02e61d50$08b257f0$@olddog.co.uk> In-Reply-To: Date: Mon, 13 Jan 2014 13:57:06 -0000 Message-ID: <028101cf1067$58980f30$09c82d90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIqywgEXUsQFAi/35YCYdcqL44SwwIO0+fTAUVZe1mZsJZkwA== Content-Language: en-gb Cc: forces@ietf.org Subject: Re: [forces] Exception ID definition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:57:20 -0000 Yes, you could use another I-D in the pipe. But I prefer that you don't just "bolt it on" to an I-D. It ought to be intuitive which document this new code point assignment is in. You could, for example, run this as a separate I-D or a revised I-D in a matter of a few weeks. A > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: 13 January 2014 12:25 > To: Adrian Farrel > Cc: forces@ietf.org > Subject: Re: Exception ID definition > > Adrian, > What about the protocol extension document (since this is > a protocol definition extension)? > > cheers, > jamal > > On Mon, Jan 13, 2014 at 7:21 AM, Adrian Farrel wrote: > > Hi Jamal, > > Yes, you can't fix this with an Errata Report. You need a new RFC. > > Either a revision of an existing RFC, or a new mini-RFC. Or fix it using the > > inter-FE ID (least preferred). > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > >> Sent: 13 January 2014 12:05 > >> To: forces@ietf.org > >> Cc: Adrian Farrel > >> Subject: Exception ID definition > >> > >> While reviewing inter-FE ID (it is about to expire), we noted that > >> we would need to transfer about Exception data. Therefore > >> we would need a TLV type for exception IDs defined. > >> Exception IDs are first used in the LFB lib. Unfortunately we missed > >> to reflect it in that doc's IANA section. So it is an error in that doc. > >> > >> What is the best way to fix this? > >> Would the new protocol extension be the right place to ask for such > >> a definition? > >> > >> cheers, > >> jamal > > From hadi@mojatatu.com Mon Jan 13 06:29:08 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2C31ADF38 for ; Mon, 13 Jan 2014 06:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 8LGk4_FrVlCm for ; Mon, 13 Jan 2014 06:29:07 -0800 (PST) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 02F581ADF23 for ; Mon, 13 Jan 2014 06:29:06 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id jx11so5173201veb.6 for ; Mon, 13 Jan 2014 06:28:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qlZ9TZkBGip7Yvx93nMkQx0a924fQiXuxRltfcm+9Ds=; b=P/hUgilZIA/tWGyD9CO4ZSlDs7wwJ5ecaLEEW26creYiXkzktaDCK2c++UzIVqCkMq 1ULkMFDFCokaUU0ZJsQxxjaoPGmlkeutTND9h7BuwGScjsm0i+ndR7ViW1zXzj6c5EvM q1hEKZ63Hbg+5PX+d9o8ToHBQQyTrtT3KuscORKStomX51tpA986NlG4LvFh3Rlaa7Ws QeDEokf/1HqnzywI8PqzL6K8V3TqJ95Fglyw+tr7vOLAQ7L3eFcJUY8KSw47xriWME0t QvVj5X+AQvx9rsrwt/jU62sNyaC1brsMm1Ioc3lvumV17jHaZJCY2l+VktcpiiNcPdq9 yJQQ== X-Gm-Message-State: ALoCoQmgSNdiuHZDltIL3ZUo0RT7Wm4vSJCLg+mLuQiC4XQvMc0MX1as8c67Kc5PIG6X05dxaFVF X-Received: by 10.58.133.193 with SMTP id pe1mr139579veb.58.1389623335888; Mon, 13 Jan 2014 06:28:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Mon, 13 Jan 2014 06:28:35 -0800 (PST) In-Reply-To: <00cc01cf1063$dd346940$979d3bc0$@com> References: <00cc01cf1063$dd346940$979d3bc0$@com> From: Jamal Hadi Salim Date: Mon, 13 Jan 2014 09:28:35 -0500 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] Protocol extension comments X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:29:08 -0000 Greetings Evangelos, On Mon, Jan 13, 2014 at 8:32 AM, Haleplidis Evangelos wrote: > Greetings Jamal, > > > I have the following comments for the > http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-02. > > > 1. There is already a wg item with the same name. > > http://tools.ietf.org/html/draft-ietf-forces-protoextension-00 > > http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-02 (there is a > typo in this name, "extenstion") You updated the non-wg. These comments are > for the updated one. > Brain fart on my side. I received an email saying draft-jhs-forces-protoextenstion-02 was expiring. So i updated it to match current consensus. I should have ignored the expiry notice. Since there is no rush - I will update draft-ietf-forces-protoextension-00 later. I will consider what i just published as more up to date. > > 2. Table-range: > > I would suggest you add what happens when someone does a table-range > get/set/del but the component is NOT a table. > > Which error code should it return? Should we create a new one, e.g. > E_COMPONENT_NOT_A_TABLE? > Added. > > > 3. Table-range: > > Just a suggestion. Show the Table-Range-TLV. Something like the following: > > +---------------------+---------------------+ > > | Type | Length | > > +---------------------+---------------------+ > > | Start Index | > > +---------------------+---------------------+ > > | End Index | > > +---------------------+---------------------+ > Ok. > > > 4. Extended Result TLV: > > This requires a necessary change to the FEPO. > > Is it possible to include this change to the 1.1 required by the CEHA > document, in order not to do too many versions? > I think you are reffering to the XXX at the end of section 4. FEPO changes make sense - but there's an additional comment I made there: "Alternatively, the backward compatibility can be made a configuration option (which helps reduce clutter on FEPO LFB given that it is expected that in the future it makes sense for implementations to support only extended Result TLVs). " It is getting annoying having to redo FEPO every time. > > > 5. There are some typo's as well inside the document (e.g. "upto", or in > some bullet points you have half sentences starting with capital, the rest > with non-capital). > No rush - but if you can be more specific it would help me fix the text faster. cheers, jamal > > > Regards, > > Evangelos Haleplidis. > > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Tue Jan 14 06:05:33 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4481AE0EB for ; Tue, 14 Jan 2014 06:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 pnwIg7e7YWXh for ; Tue, 14 Jan 2014 06:05:31 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 71C201AE0E9 for ; Tue, 14 Jan 2014 06:05:31 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id w20so1482802vbb.13 for ; Tue, 14 Jan 2014 06:05:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=QSlxcco+1csuw9Z4Y2u0Whv/Xf8JS7fqD2S9enkoO3Q=; b=VU/5tLsELKBmdOOW+OjGQ29hHKXsKUBdUkcL4cpOYpi8nhN1cTl5IhUk0FqpOYjJGy I3Wq/XZFs+jw7fwsxbmR1e3bTWUA8+cODR2kN93QgQPwloCEqV2xKnrpYOeA9lc4qXgk CHS3xVBPMHZieiknmwVtkeSog62kXckm3MkH4U+a6RZ1SqhHWy/wcDG1JsRwHCbogJ13 FDmrsaaDjCu1kYd3QsXf3BG1QOo4jdYMrIiUKUz2Iw40BXoNIe6Rq6sCUDaNsYkgiXeP y3RhFjma5ceDespnze8wNGwvQDchxti9V+dP5nsZMJ1tHYgSLmnjIUrmCbq4Pq6NkK0N iDog== X-Gm-Message-State: ALoCoQkVfO2wPLGTpdxkHXD7Z49FR7fWiFP3K+v5ofBnsnqNKrIBfEviuhs+5y30RAH4guSoAxzF X-Received: by 10.221.24.200 with SMTP id rf8mr178934vcb.65.1389708319874; Tue, 14 Jan 2014 06:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 14 Jan 2014 06:04:58 -0800 (PST) In-Reply-To: <4105A88A-91D5-4321-B215-CFA96AE3208F@affirmednetworks.com> References: <4105A88A-91D5-4321-B215-CFA96AE3208F@affirmednetworks.com> From: Jamal Hadi Salim Date: Tue, 14 Jan 2014 09:04:58 -0500 Message-ID: To: Ron Parker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "forces@ietf.org" , sfc Subject: Re: [forces] [sfc] comments on draft-quinn-sfc-problem-statement-02 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:05:33 -0000 Hi Ron, On Tue, Jan 14, 2014 at 7:55 AM, Ron Parker wrote: > Hi, Jamal. > > I'm not very familiar with the details of FORCES, so I have a few questio= ns. > > Just as the referenced slide points out that DPI at every service functio= n is undesirable, it may be that fully qualified flow tracking at every ser= vice function is undesirable, too, although clearly some will need to in or= der to perform their function. How would FORCES handle that? Would full= flow learning become mandatory? > The whole point behind pipeline indexing is to avoid things of that sort. It would be upto the service definition: as an _example_, something like DPI would happen at one stage of the pipeline and the results are useable further down stream. > In FORCES, Is there a signaling component operating at the fully qualifie= d flow level? In a network with 10's or 100's of millions of active fully = qualified flows, what are the scaling properties of FORCES? > I am not sure i understood the context of "fully qualified flow level" but let me see if i can answer your question (and i worry this list is the wrong place for such a discussion, come to the ForCES list which I am CCing with any further discussion). ForCES defines a model per network function. (ForCES term for a network function would be LFB). A service would then be a graph of instantiated network functions To your scaling question. You scale the service either: - vertically by using a higher performing network function (eg an ASIC assisted DPI engine as opposed to purely software running in user space) - horizontally as specified by creating appropriate service graphs that pipeline (as pointed in that draft) or you could go further and use systolic approaches (as an example take a look at: http://tools.ietf.org/search/draft-haleplidis-forces-packet-paralleliza= tion-04) Now - dont let the two drafts confuse you because they take a very fine gra= ined approach to what a network function. The protocol is designed to be scale for control activities where throughput and latency are relevant attributes. It is also used for management where usability maybe more of value. So scaling was an important part of the initial design. Not sure if i answered your question. If you want a quick dump on the features: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-2.pdf We are working to publish a tutorial RSN. cheers, jamal > Thanks. > > Ron > > >> On Jan 14, 2014, at 6:17 AM, "Jamal Hadi Salim" wrot= e: >> >> Some context: >> ForCES is defining what is known as the inter-FE LFB >> (http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03) >> to describe chaining of network functions. >> >> One of the desires ForCES has is for horizontal scaling of >> network functions/service. >> We would like to take a network function or service and split >> its parts across several processing resources. This requires to >> pass around relevant "Pipeline stage indices" >> Brad McConnell did touch on it here (slide 6): >> http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf >> >> This view is missing from the problem space. >> >> Additionally - we have a requirement to be able pass arbitrary >> metadata between nodes (means desire to have more than just >> basic 32/64 bit constructs) >> >> cheers, >> jamal >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc