From ietf-secretariat-reply@ietf.org Fri May 3 12:12:37 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B8021F9343 for ; Fri, 3 May 2013 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.842 X-Spam-Level: X-Spam-Status: No, score=-101.842 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rJxrPHfrYfN; Fri, 3 May 2013 12:12:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6882821F91B0; Fri, 3 May 2013 12:12:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: forces@ietf.org, forces-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130503191237.26308.41542.idtracker@ietfa.amsl.com> Date: Fri, 03 May 2013 12:12:37 -0700 From: IETF Secretariat Subject: [forces] State changed: charter-ietf-forces-03-07 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:12:37 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-forces/ From stbryant@cisco.com Wed May 8 02:08:53 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C421F8F0C; Wed, 8 May 2013 02:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7h+rFFCm9Kc; Wed, 8 May 2013 02:08:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B286521F84F8; Wed, 8 May 2013 02:08:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130508090851.7682.25972.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 02:08:51 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Stewart Bryant's No Objection on charter-ietf-forces-03-07: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:08:53 -0000 Stewart Bryant has entered the following ballot position for charter-ietf-forces-03-07: 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.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "1. Allow complex metadata" A plate of spaghetti is a complex. Hopefully you mean "compound" or "structured"?. From hadi@mojatatu.com Wed May 8 05:56:43 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4340321F9301 for ; Wed, 8 May 2013 05:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIRnFAaOKPq0 for ; Wed, 8 May 2013 05:56:42 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2321F91CA for ; Wed, 8 May 2013 05:56:39 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji2so877434bkc.10 for ; Wed, 08 May 2013 05:56:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=UUG5pgiRQSh8E49Jbtys2PF/3WY5i2D28CmAKHhj9IA=; b=EWnhDElHD3Q5wnEOgXASyBZuBkkGxb8105rEkIxjohTymnhmMU/z5tH47E3fbugsMC 2GFZCIaIjW+jLEBboAGNa/FeyQpmpznbHP/OS957WLkWLyUlktm/Tu8/WVeUnYAeiMB0 NtloCAWeBECNhWh3GCW+I5xmAchW2ny2Q3R3wzJReP3HA961yjmiWCxsrBE8juTE6Re2 6+/BDYjKrIqre2OiKZh2bLnLh0DMsY3c7wY5xyW9rNMg/BGljuYeVfzs4vIRvT5m6V6H HGJ2rdXGCpofnIzXgEXfihjLy3iKGUIolHz48y8lYPc6YXit9y9kdhRG5Ci/FpSLieb9 NUQQ== X-Received: by 10.204.186.67 with SMTP id cr3mr1852888bkb.14.1368017799042; Wed, 08 May 2013 05:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.173.137 with HTTP; Wed, 8 May 2013 05:56:17 -0700 (PDT) In-Reply-To: References: <003301ce45ab$5067d7f0$f13787d0$@com> From: Jamal Hadi Salim Date: Wed, 8 May 2013 08:56:17 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=20cf301e2e45f595c204dc347628 X-Gm-Message-State: ALoCoQlvsVnbOHowBQc6+lwpffbCsU/Z02RIKEJ9WrF45NwapDKbskdWMo116LLiEfyxf0xydV5u Cc: draft-ietf-forces-ceha@tools.ietf.org, "forces@ietf.org" Subject: Re: [forces] Fwd: Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 12:56:43 -0000 --20cf301e2e45f595c204dc347628 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Evangelos/Bhumip, Lets move forward to get this last document published. I dont see much of a show stopper in the exchanges. If Bhumip has still issues - we can address them then. cheers, jamal On Tue, Apr 30, 2013 at 10:19 AM, Jamal Hadi Salim wrote= : > > > On Tue, Apr 30, 2013 at 10:02 AM, Haleplidis Evangelos = wrote: > >> >> (8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8, and >> Reserve these for future use**** >> >> (9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it for >> future use **** >> >> *[=C5=C7] For 8 & 9, my current thinking is that they are unnecessary. >> Tampering with the FEPO special values may result in non-interoperable >> implementations of ForCES. Changes for these special values should be do= ne >> within the ForCES working group.* >> >> *Why do you think this is required? Anyone else=A2s thoughts on this?* >> > > > Agree with Evangelos. > There is no need to reserve fields for future use. It will infact cause > interop problems if someone > starts using those fields. > > > cheers, > jamal > --20cf301e2e45f595c204dc347628 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
Evangelos/Bhumip,

Lets move forward to = get this last document published. I dont see much
of = a show stopper in the exchanges. If Bhumip has still issues - we can addres= s
them then.

cheers,
jamal


On Tue, Apr 30, 2013 at 10:19 AM, Jamal Ha= di Salim <hadi@mojatatu.com> wrote:


On Tue, Apr 30, 2013 a= t 10:02 AM, Haleplidis Evangelos <ehalep@gmail.com> wrote:


(8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8,= =A0 and Reserve these for future use<= /u>

(9)In Sec. 4.1 und= er 2, please consider adding, +3, and Reserve it for future use=A0 <= u>

= [=C5=C7] For 8 &= amp; 9, my current thinking is that they are unnecessary. Tampering with th= e FEPO special values may result in non-interoperable implementations of Fo= rCES. Changes for these special values should be done within the ForCES wor= king group.

Why do you think this = is required? Anyone else=A2s thoughts on this?



Agree wit= h Evangelos.
There is no need to reserve fields for future use. I= t will infact cause interop problems if someone
starts using thos= e fields.


cheers,
jamal

--20cf301e2e45f595c204dc347628-- From internet-drafts@ietf.org Wed May 8 06:35:31 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DB721F93D6; Wed, 8 May 2013 06:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZrjGSXNYwAh; Wed, 8 May 2013 06:35:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AADD21F93BF; Wed, 8 May 2013 06:35:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130508133530.25622.31933.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 06:35:30 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-ceha-07.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 13:35:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Intra-NE High Availability Author(s) : Kentaro Ogawa Weiming Wang Evangelos Haleplidis Jamal Hadi Salim Filename : draft-ietf-forces-ceha-07.txt Pages : 26 Date : 2013-05-08 Abstract: This document discusses Control Element High Availability within a ForCES Network Element. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-ceha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-ceha-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-ceha-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Wed May 8 07:49:01 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6421F92A5; Wed, 8 May 2013 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FyccMKaDLwB; Wed, 8 May 2013 07:48:52 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E34FB21F873D; Wed, 8 May 2013 07:48:51 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r48EmmP0019320; Wed, 8 May 2013 15:48:48 +0100 Received: from 950129200 ([193.1.64.8]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r48EmleN019306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 May 2013 15:48:47 +0100 From: "Adrian Farrel" To: "'Stewart Bryant'" , "'The IESG'" References: <20130508090851.7682.25972.idtracker@ietfa.amsl.com> In-Reply-To: <20130508090851.7682.25972.idtracker@ietfa.amsl.com> Date: Wed, 8 May 2013 15:48:44 +0100 Message-ID: <01a201ce4bfb$23f757d0$6be60770$@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: AQLMZxIH8/DelWkjQzhCSrHVDYCMv5b/J2cg Content-Language: en-gb Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: Re: [forces] Stewart Bryant's No Objection on charter-ietf-forces-03-07: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 08 May 2013 14:49:02 -0000 Edit made. Thanks, Adrian > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: 08 May 2013 10:09 > To: The IESG > Cc: forces@ietf.org; forces-chairs@tools.ietf.org > Subject: [forces] Stewart Bryant's No Objection on charter-ietf-forces-03-07: > (with COMMENT) > > Stewart Bryant has entered the following ballot position for > charter-ietf-forces-03-07: 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.) > > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "1. Allow complex metadata" > > A plate of spaghetti is a complex. Hopefully you mean "compound" or > "structured"?. > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From ted.lemon@nominum.com Sun May 12 09:22:57 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B561A21F89C3; Sun, 12 May 2013 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0649x7aKrd2U; Sun, 12 May 2013 09:22:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDFA21F8916; Sun, 12 May 2013 09:22:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130512162256.3612.1711.idtracker@ietfa.amsl.com> Date: Sun, 12 May 2013 09:22:56 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Ted Lemon's No Objection on charter-ietf-forces-03-08: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 16:22:58 -0000 Ted Lemon has entered the following ballot position for charter-ietf-forces-03-08: 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.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Inter-FE connectivity: s/Logigal/Logical/ The charter is nice and tight. From spencer@wonderhamster.org Wed May 15 12:07:18 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D784D21F9227; Wed, 15 May 2013 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVmHY5NB2avd; Wed, 15 May 2013 12:07:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB2721F913E; Wed, 15 May 2013 12:07:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515190717.6695.51615.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 12:07:17 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Spencer Dawkins' No Objection on charter-ietf-forces-03-09: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 19:07:19 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-forces-03-09: 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.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My apologies for not noticing this previously, and if it's been discussed, I didn't see it in the tracker ... In this text: In addition to the specific work items listed above, the working group will allow discussions and review work of how to use ForCES to model topics of interest to Network Function Virtualization, I2RS, or OpenFlow. is "or OpenFlow" too specific? One answer could be "no" ... From adrian@olddog.co.uk Wed May 15 14:19:09 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C311E80D2; Wed, 15 May 2013 14:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U8GAT9q2NaR; Wed, 15 May 2013 14:19:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 88A5A11E80A3; Wed, 15 May 2013 14:19:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4FLJ17b021901; Wed, 15 May 2013 22:19:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4FLJ09m021885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 May 2013 22:19:01 +0100 From: "Adrian Farrel" To: "'Spencer Dawkins'" , "'The IESG'" Date: Wed, 15 May 2013 22:18:58 +0100 Message-ID: <00e501ce51b1$d1333b60$7399b220$@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: Ac5RsbNDbkRlqOmPQkujGCoBkK5OdQ== Content-Language: en-gb Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: Re: [forces] Spencer Dawkins' No Objection on charter-ietf-forces-03-09: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 15 May 2013 21:19:09 -0000 Hi Spencer, Clearly we didn't think it was too specific. What is your concern? (BTW there is already some work in this area.) A > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > My apologies for not noticing this previously, and if it's been > discussed, I didn't see it in the tracker ... > > In this text: > > In addition to the specific work items listed above, the working group > will allow discussions and review work of how to use ForCES to model > topics ofinterest to Network Function Virtualization, I2RS, or > OpenFlow. > > is "or OpenFlow" too specific? One answer could be "no" ... From spencer@wonderhamster.org Thu May 16 06:51:56 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2FE21F9344; Thu, 16 May 2013 06:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNTEUn2t1kxe; Thu, 16 May 2013 06:51:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A8BCE21F9354; Thu, 16 May 2013 06:51:50 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MCKpF-1Um18Q2r1V-0098zk; Thu, 16 May 2013 09:51:48 -0400 Message-ID: <5194E477.5040405@wonderhamster.org> Date: Thu, 16 May 2013 08:51:51 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <00e501ce51b1$d1333b60$7399b220$@olddog.co.uk> In-Reply-To: <00e501ce51b1$d1333b60$7399b220$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:/f1aUTUCKo7ynjlRdOZau9Bio+oY72vVXoznvCeJEy7 TAJrXfNv+XyRE6nSipYU+7QUiAvXr7QyRwEFzcsXe4s56x/bS6 bJ0Tf0Qirng6QHvCGoESvIS4HIn1ZMrtLvgJU35HZ+vuHJA2B4 9ITTRVrRaflCxfO37zl9PWSKyQkuRBFqMDCoyZtLM9i6YM/GpL eygH9whbdMdG3WH9Lizyj7yGfy0UJj1NC0XlD7qEIWUFkhEZzC cBfWNcB/rGMtiDDMuO1c8FNX4+wroiYYICg3TU293XBCaL12pG xZdAR+yhdU67B+i6SS0KUCd46aJLG1WW/ee2cAT5d99Zqg0fmG 0xLJozRrkTLM2CyKrlPK+ptaqxMN6f7qQNVJkny/W Cc: forces@ietf.org, forces-chairs@tools.ietf.org, 'The IESG' Subject: Re: [forces] Spencer Dawkins' No Objection on charter-ietf-forces-03-09: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 13:51:56 -0000 On 5/15/2013 4:18 PM, Adrian Farrel wrote: > Hi Spencer, > > Clearly we didn't think it was too specific. > What is your concern? > (BTW there is already some work in this area.) Adrian, Joel e-mailed me privately about this. My question was whether there was anything besides OpenFlow, that was smaller than SDN (Joel's feedback to me), that might be of interest. My understanding is that if some "FlowOpen" popped up that wasn't OpenFlow, the working group would need to recharter to have that in scope. If no one smarter than me thinks that's likely, I certainly don't see a problem. >> is "or OpenFlow" too specific? One answer could be "no" ... And that can be an answer that I'm fine with :-) Spencer From adrian@olddog.co.uk Thu May 16 09:57:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0382921F93D4 for ; Thu, 16 May 2013 09:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMD6pEUpYF0D for ; Thu, 16 May 2013 09:57:33 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 203F321F93A5 for ; Thu, 16 May 2013 09:57:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4GGvUsG026544 for ; Thu, 16 May 2013 17:57:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4GGvTfq026531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 May 2013 17:57:30 +0100 From: "Adrian Farrel" To: Date: Thu, 16 May 2013 17:57:27 +0100 Message-ID: <027401ce5256$72a78790$57f696b0$@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: Ac5SVdzjxfrwzUIrTeusTxlg0vISrA== Content-Language: en-gb Subject: [forces] Your recharter is approved X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 16 May 2013 16:57:38 -0000 Hi, The IESG just approved your recharter. The text is currently visible at https://datatracker.ietf.org/doc/charter-ietf-forces/ and will be updated on your main charter page soon. What are you waiting for? get on with your work :-) Adrian From adrian@olddog.co.uk Thu May 16 10:08:12 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311ED11E811A for ; Thu, 16 May 2013 10:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+to95k2j7dU for ; Thu, 16 May 2013 10:07:58 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D694B21F8F28 for ; Thu, 16 May 2013 10:07:57 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4GH7sWe002479; Thu, 16 May 2013 18:07:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4GH7hYP002447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 May 2013 18:07:51 +0100 From: "Adrian Farrel" To: Date: Thu, 16 May 2013 18:07:41 +0100 Message-ID: <027701ce5257$e49ab6a0$add023e0$@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: Ac5SV1DSOjDbFyADSLWF9JOuJESbxA== Content-Language: en-gb Cc: joel.halpern@ericsson.com Subject: [forces] New ForCES co-chair X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 16 May 2013 17:08:12 -0000 Hi, In time for your recharter, I am very pleased to announce that DJ has agreed to be your new co-chair. Please welcome him and work with him and Jamal to deliver your work items. At the same time, Joel has agreed to serve as the working group's Technical Adviser. Both points will be recorded on the charter page. Thanks, Adrian From hadi@mojatatu.com Thu May 16 15:23:15 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3692011E80CC for ; Thu, 16 May 2013 15:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmThTcb6-yv7 for ; Thu, 16 May 2013 15:23:14 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AC80211E80AE for ; Thu, 16 May 2013 15:23:14 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cy12so3514446veb.32 for ; Thu, 16 May 2013 15:23:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=XaF+fPnK5yTkBcMyH5expVwWZGgKZO8k6xeM0GHNLsE=; b=CQW1jQ5JaI5m8cNf5X25kImHWZ5XfK8NeFpU0+vbctT3kFitxikpgr4vAQaqnch7Jr ydccLHOO9Eh7sdAZhkw70zwM35NO69cgNKthTyyhD4e+hZ1CGDYzFOBdFjZoEcwMlxNm H1qz2nHO+hmCiFfQKSxT/uqse7gzvUJ/nhrlYRZ6RfGIDHuwHn0eVGEMIZSd+gyfRhLd iuRwX7VfNKe1Oni/eqLf4P5m2Z04+aaPVWoaIWxAAAgAJCi5jdvxEtd+spZx8G9Lx5OK /fBZ9PcXIV9do0K4TVK1xWUBLAtXARhl45Gc7kGopqed/TjHLMFulLudmJs3swZnB7Gv a/Yg== X-Received: by 10.52.29.142 with SMTP id k14mr24348230vdh.124.1368742993748; Thu, 16 May 2013 15:23:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.204.129 with HTTP; Thu, 16 May 2013 15:22:48 -0700 (PDT) In-Reply-To: <027701ce5257$e49ab6a0$add023e0$@olddog.co.uk> References: <027701ce5257$e49ab6a0$add023e0$@olddog.co.uk> From: Jamal Hadi Salim Date: Thu, 16 May 2013 18:22:48 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=20cf307d041cee770b04dcdd4f4e X-Gm-Message-State: ALoCoQmsU615eoheVLIbPXvK+TLLVNMNcfs4w+EwDMLDqVu8QQshgY8b2/lYHW1lgZXXg/2uCgJ/ Cc: Joel Halpern , "forces@ietf.org" Subject: Re: [forces] New ForCES co-chair X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 22:23:15 -0000 --20cf307d041cee770b04dcdd4f4e Content-Type: text/plain; charset=ISO-8859-1 Welcome aboard DJ! Looking forward to work with you and Joel. cheers, jamal On Thu, May 16, 2013 at 1:07 PM, Adrian Farrel wrote: > Hi, > > In time for your recharter, I am very pleased to announce that DJ has > agreed to > be your new co-chair. Please welcome him and work with him and Jamal to > deliver > your work items. > > At the same time, Joel has agreed to serve as the working group's Technical > Adviser. > > Both points will be recorded on the charter page. > > Thanks, > Adrian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --20cf307d041cee770b04dcdd4f4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Welcome aboard DJ!=A0
Looking forward to work with you= and Joel.

cheers,
jamal


On Thu, May 16, 2013 at 1:07 PM, Adrian Farrel <adrian@olddog.co.uk&= gt; wrote:
Hi,

In time for your recharter, I am very pleased to announce that DJ has agree= d to
be your new co-chair. Please welcome him and work with him and Jamal to del= iver
your work items.

At the same time, Joel has agreed to serve as the working group's Techn= ical
Adviser.

Both points will be recorded on the charter page.

Thanks,
Adrian

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

--20cf307d041cee770b04dcdd4f4e-- From damascene.joachimpillai@verizon.com Fri May 17 05:53:36 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C25221F8AD8 for ; Fri, 17 May 2013 05:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9vny0YxhByi for ; Fri, 17 May 2013 05:53:30 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0F21F89C3 for ; Fri, 17 May 2013 05:53:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 17 May 2013 12:53:27 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.87,692,1363132800"; d="scan'208,217";a="473383712" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 17 May 2013 12:53:17 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 17 May 2013 08:53:16 -0400 To: Jamal Hadi Salim , Adrian Farrel Date: Fri, 17 May 2013 08:53:16 -0400 Thread-Topic: [forces] New ForCES co-chair Thread-Index: Ac5ShAn+HhzmCG4bSXyMKqcTZOQsDQAeV7AQ Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB011D13E338@FHDP1LUMXC7V31.us.one.verizon.com> References: <027701ce5257$e49ab6a0$add023e0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011D13E338FHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: Joel Halpern , "forces@ietf.org" Subject: Re: [forces] New ForCES co-chair X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 12:53:36 -0000 --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011D13E338FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jamal. Looking forward to working with you and the team and move the= charter forward. n DJ From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Jamal Hadi Salim Sent: Thursday, May 16, 2013 6:23 PM To: Adrian Farrel Cc: Joel Halpern; forces@ietf.org Subject: Re: [forces] New ForCES co-chair Welcome aboard DJ! Looking forward to work with you and Joel. cheers, jamal On Thu, May 16, 2013 at 1:07 PM, Adrian Farrel > wrote: Hi, In time for your recharter, I am very pleased to announce that DJ has agree= d to be your new co-chair. Please welcome him and work with him and Jamal to del= iver your work items. At the same time, Joel has agreed to serve as the working group's Technical Adviser. Both points will be recorded on the charter page. Thanks, Adrian _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011D13E338FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ja= mal. Looking forward to working with you and the team and move the charter = forward.

 =

n  DJ

 <= /span>

From: forces-bounces@ietf.org [mailto:forces-b= ounces@ietf.org] On Behalf Of Jamal Hadi Salim
Sent: Thurs= day, May 16, 2013 6:23 PM
To: Adrian Farrel
Cc: Joel Ha= lpern; forces@ietf.org
Subject: Re: [forces] New ForCES co-chair<= o:p>

 

Welcome aboard DJ! 

Looking forward to work with you and Joel.

 

cheer= s,

jamal

=

=  

On Thu, May 16, 2013 at 1:07= PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

= Hi,

In time for your recharter, I am very pleased to announce that D= J has agreed to
be your new co-chair. Please welcome him and work with h= im and Jamal to deliver
your work items.

At the same time, Joel h= as agreed to serve as the working group's Technical
Adviser.

Both= points will be recorded on the charter page.

Thanks,
Adrian
<= br>_______________________________________________
forces mailing listforces@ietf.org
https://www.iet= f.org/mailman/listinfo/forces

=  

= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011D13E338FHDP1LUMXC7V3_-- From iesg-secretary@ietf.org Fri May 17 09:13:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C2121F96AB; Fri, 17 May 2013 09:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTR7hjKjeEvJ; Fri, 17 May 2013 09:13:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B3921F96B0; Fri, 17 May 2013 09:13:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130517161338.26584.11543.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 09:13:38 -0700 Cc: forces WG Subject: [forces] WG Action: Rechartered Forwarding and Control Element Separation (forces) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:13:41 -0000 The Forwarding and Control Element Separation (forces) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Forwarding and Control Element Separation (forces) ------------------------------------------------ Current Status: Active Working Group Chairs: Damascane Joachimpillai Jamal Hadi Salim Technical advisors: Joel Halpern Assigned Area Director: Adrian Farrel Mailing list Address: forces@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/forces Archive: http://www.ietf.org/mail-archive/web/forces/ Charter of Working Group: The ForCES working group has created a framework, requirements, a solution protocol, a logical function block library, and other associated documents in support of Forwarding and Control Element Separation. Drawing on the experience gained from developing the standards and from many efforts using this architecture, the ForCES working group is now working on a set of additions to the model, the protocol, and the libraries. The following 5 work items are the chartered tasks of this working group: o Extensions to Model and Protocol This work is to address a set of extensions to the base model and protocol resulting in updates to RFCs 5810 and 5812. This effort will produce 2 Standards Track documents (one for the model and another for the protocol). The model extensions will: 1. Allow compound metadata 2. Allow optional default values for datatypes 3. Allow optional access-type for datatypes inside complex components 4. Define new base type: Bitmap 5. Define new events to monitor states. The protocol extensions will: 1. Support table range query 2. Support table append 3. Define additional return codes to reduce ambiguity 4. Define data packing rule for bitmap datatype. o Inter-FE Connectivity ForCES processing is often spread across multiple Forwarding Elements (FEs). The original framework identified the interface between FEs as the "Fi" reference point. Protocol and Logical Function Block (LFB) mechanisms to carry metadata across the Fi interface are needed. This effort will produce a standards track document defining the protocol on the wire to address this need, and the LFBs used to represent the Interfaces for sending and receiving such information. It is expected that this work will draw heavily on existing protocol and LFB definitions. o Parallelization An FE can implement an LFB chain with parallelization, but the currently-defined mechanism has no means to represent when synchronization is needed, or to allow the CE to specify where it believes such parallelism is useful. This work item will produce a single standards track document to improve the handling of this case. o Subsidiary Management Deployment experience has demonstrated the value of using ForCES to control the Forwarding Element Manager (FEM) by creating an LFB to represent its function using the same encoding rules as for any other LFB. This allows it to be controlled by the same Control Element (CE). This work item assumes the presence of an initially booted FE whose configuration could then be updated at runtime via an FEM LFB for runtime config purposes (e.g., by adding a new CE and its associated IP address). This work item can also be useful in addressing control of virtual FEs where individual FEM Managers can be addressed to control the creation, configuration, and resource assignment of such virtual FEs within a physical FE. This work would result in a standards track LFB FEM library RFC. In addition to the specific work items listed above, the working group will allow discussions and review work of how to use ForCES to model topics of interest to Network Function Virtualization, I2RS, or OpenFlow. It is understood that the primary responsibility for such documents lives with other working groups, individual contributions, or other standards bodies. Milestones: Done - Submit requirements document to IESG Done - Submit framework document to IESG Done - Submit forwarding element functional model document to IESG Done - Submit formal definition of controlled objects in functional model Done - Submit protocol selection/definition document to IESG Sep 2013 - Request for Publication of Standards Track document specifying model changes Sep 2013 - Request for Publication of Standards Track document specifying protocol changes Feb 2014 - Request for publication of Subsidiary management LFB Mar 2014 - Request for publication of Inter-FE LFB Mar 2014 - Request for publication of parallelization LFBs Apr 2014 - Recharter or shutdown From hadi@mojatatu.com Thu May 23 05:47:30 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFE621F91BC for ; Thu, 23 May 2013 05:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPgYWD44gHY8 for ; Thu, 23 May 2013 05:47:30 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0904021F93A6 for ; Thu, 23 May 2013 05:47:27 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 15so2381657vea.29 for ; Thu, 23 May 2013 05:47:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=Z2xsjdbCQNBElOs/AUHTl8gtSE2NEw/VDAS/cYQm3cQ=; b=a0/sWQ0JFlOndicWw44EnR4IHh2wiZ0t5tlhGxUtw86aJ3WbxeYctYFtrgV6kdQR5J wLpB8UKT1zsY94cEJ2jVeeseqDsH6c4KGOXpR1qiht3PayDGWcslCGKf40jo+BoESA72 E4kxxEOMkE0MEbzEsK2PvYeEl5rh6tzP02EdQOWyOubh6GQ5XC29GmwB/sjsFbgHRxeK dgIInzviowL/s96OtWVIzMKDXplmGq/CPCKND7cZxVLi+AdSRKgoL4fMKU/06r3hvES7 UNfw6dYD7hw6svbulBB17FsMzc6hf9DdrgVsEUIb12+YolGo9cMD7jnibOnPITyP9MY9 7AHA== X-Received: by 10.59.2.199 with SMTP id bq7mr4982494ved.51.1369313247086; Thu, 23 May 2013 05:47:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.155.71 with HTTP; Thu, 23 May 2013 05:47:06 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 23 May 2013 08:47:06 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04ce6addc6c04dd621535 X-Gm-Message-State: ALoCoQlaizHASOR96AspO42dpaYFSe51bT5pa6TVyEVX3zZz1VlOz2HPELhBhiHfEFQCCVks/80V Cc: Bhumip-ZTE Khasnabish Subject: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:47:30 -0000 --047d7bb04ce6addc6c04dd621535 Content-Type: text/plain; charset=ISO-8859-1 Bhumip has graciously agreed to shepherd the CEHA draft: https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/ This the last outstanding document from the previous charter that has not started the publication journey. Thanks Bhumip. cheers, jamal --047d7bb04ce6addc6c04dd621535 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Bhumip has graciously agre= ed to shepherd the CEHA draft:=A0
https://datatracker.ietf.org/doc/draft-iet= f-forces-ceha/

This the last outstanding document from the previ= ous charter that
has not started the publication journey.

Thanks Bhumip.

cheers,
jamal
--047d7bb04ce6addc6c04dd621535-- From internet-drafts@ietf.org Thu May 23 08:53:36 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A36F21F982F; Thu, 23 May 2013 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFthOjResyto; Thu, 23 May 2013 08:53:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD39121F982C; Thu, 23 May 2013 08:53:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523155333.26079.5506.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 08:53:33 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-interop-08.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:53:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Eleme= nt Separation (ForCES) Author(s) : Weiming Wang Kentaro Ogawa Evangelos Haleplidis Ming Gao Jamal Hadi Salim Filename : draft-ietf-forces-interop-08.txt Pages : 28 Date : 2013-05-23 Abstract: This document captured results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. RFC 6053 has reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-interop-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-interop-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmwang2001@hotmail.com Thu May 23 09:30:53 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9478621F972D for ; Thu, 23 May 2013 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi9IHwY7E56l for ; Thu, 23 May 2013 09:30:38 -0700 (PDT) Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by ietfa.amsl.com (Postfix) with ESMTP id 680D321F9709 for ; Thu, 23 May 2013 09:30:36 -0700 (PDT) Received: from BLU0-SMTP38 ([65.55.111.137]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 May 2013 09:30:36 -0700 X-EIP: [JuA06oYpjmFJur7EhveegYddNPk/Ek17] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([125.120.89.142]) by BLU0-SMTP38.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 May 2013 09:30:35 -0700 From: "Wang,Weiming" To: References: <20130523155334.26079.59380.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 00:30:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 23 May 2013 16:30:35.0378 (UTC) FILETIME=[DA137520:01CE57D2] Subject: Re: [forces] New Version Notification - draft-ietf-forces-interop-08.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:30:54 -0000 SGkgbGlzdCwNCg0KVGhlIGRyYWZ0LWlldGYtZm9yY2VzLWludGVyb3AgZG9jdW1lbnQgaGFzIGJl ZW4gbWFkZSBhIG5ldyB1cGRhdGUgdmVyc2lvbi4gDQoNClRoZSB1cGRhdGUgaXMgYmFzZWQgb24g dmFsdWJsZSBjb21tZW50cyBmcm9tIEdlbi1BUlQgTEMgcmV2aWV3ZXIgIEJlbiBDYW1wYmVsbCBh bmQgT3BlcmF0aW9ucyBEaXJlY3RvcmF0ZSByZXZpZXdlciBOZXZpbCBCcm93bmxlZS4gIA0KDQpV cGRhdGVzIGluY2x1ZGU6IA0KMS4gVGhlIGFiYnJldmlhdGlvbnMgZm9yIGltcGxlbWVudGVycw0K Mi4gVGhlIGRvY3VtZW50IGdyYW1tYXIgdGVuc2UNCjMuIG1vZGlmaWVkIHNldmVyYWwgbm90ZXMg b24gdGVzdHMgDQo0LiBtb2RpZmllZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9u DQo1LiBtb2RpZmllZCB0aGUgcmVmZXJlbmNlcw0KNi4gZml4ZWQgc29tZSBuaXRzDQoNCnRoYW5r cywNCldlaW1pbmcNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KDQpBIG5ldyB2ZXJzaW9uICgtMDgpIGhhcyBiZWVu IHN1Ym1pdHRlZCBmb3IgZHJhZnQtaWV0Zi1mb3JjZXMtaW50ZXJvcDoNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZm9yY2VzLWludGVyb3AtMDgudHh0DQoN Cg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZm9yY2VzLWludGVy b3AvDQoNCkRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1mb3JjZXMtaW50ZXJvcC0wOA0KDQpJRVRGIFNlY3JldGFy aWF0Lg0K From hadi@mojatatu.com Thu May 30 08:16:04 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365C721F93DE for ; Thu, 30 May 2013 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0x1GBYnMILW for ; Thu, 30 May 2013 08:15:58 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 821F821F93E8 for ; Thu, 30 May 2013 08:15:58 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hv10so254579vcb.20 for ; Thu, 30 May 2013 08:15:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=sjQZEFEveTirqZBYdf960qRRyCbSujjJhyU9vHUnK04=; b=giult/01hrxNmI1JCNZ0NcATT26I9lwWhYnx+Rk1QjatQX2w4IeqNDDXZAnufxPeX2 sg1wCMt+2d2DZOuUeZc5MWRHAMnk9OktlWHl0gcSTMYXjeNBR1sqbxhhHHOiXOYvTWw/ fG/4th/IEWxtIxOs6FXklrWJF6u1g5IdKDAm5xG/V8zKXc+5yDwxqs7wjRM0RMco6tlk M+k7KHIhaL8Wi99i3nU3rP4ePMpOCtUjk0RdmLudkHSvYa6hiGpPwa3TxEROaPnaNVyZ lA6V7JiGtRK4ShQ6FlBUkLQeZtgFtdjk3g6gq39uH/Srn21IcLAYqQdVrh8wJ7XA+ZTb HlKQ== X-Received: by 10.52.26.140 with SMTP id l12mr5077945vdg.29.1369926957766; Thu, 30 May 2013 08:15:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.206.13 with HTTP; Thu, 30 May 2013 08:15:37 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 30 May 2013 11:15:37 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=20cf307cfcc6afa98a04ddf0f954 X-Gm-Message-State: ALoCoQlCs7u0kckvzC/m/UqTPIn8QDdJtc/a2+c1Ix3O+p/Q6N8NG+AC4kx/9AYVDZD7/l8HnYcX Subject: [forces] on the utility of unions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:16:04 -0000 --20cf307cfcc6afa98a04ddf0f954 Content-Type: text/plain; charset=ISO-8859-1 Without going into a lot of details - this came up as i tried to implement union support in our code and a private discussion with Evangelos. I will try to sumarize but it may be a long email ;-> Unions look great from a model perspective; they also save memory use on a machine. One of the things Evangelos and I initially thought was a great idea was something like: union myaddress { 1:ipv4address ip 2:ipv6address ip6 } This looks good. I can now manipulate the component myunion from the CE. Setting path to be /myaddress/ip or /myaddress/ip6 is reasonable. And you can play small tricks to let someone use /myaddress as a path (but thats a separate topic of discussion). We get the ideal use case of unions. The challenge starts showing up when you have hierachies. Example: mystruct blah { 1: myaddress fooaddress 2: uint32 bar } There is no clean way of getting the path /blah from the FE (compare to when blah had no unions). This is because it is ambigous within /blah/myaddress whether i am referring to /blah/myaddress/ip or ip6 when i do the get. I could construct a query with multiple paths to retrieve /blah but i am questioning the usefulness of wasting wire-bits and more cpu for encoding/decoding in order to save host-bits (memory) just for the sake of being able to model something like this as a union. Things get worse if i have a table whose rows are struct blah and say i needed to dump a few table entries. Note: I left out the direction of CE->FE setting because less acrobatics involved (but still inefficient). Thoughts? My suggestion is to define things that need to be modelled this way as structs with /optional constructs. cheers, jamal --20cf307cfcc6afa98a04ddf0f954 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Without going into a lot of details - this = came up as i tried to implement
union support in our code a= nd a private discussion with Evangelos.
I will try to sumar= ize but it may be a long email ;->

Unions look great from a model perspective;= they also save memory use on
a machine.=A0
One of the things Evangelos and I initially thought was a great idea was
something like:

union myadd= ress {
=A0 =A0 =A0 =A0 =A01:ipv4address ip=A0
=A0 =A0 =A0 =A0 =A02:ipv6address ip6
}
<= br>
This looks good. I can now manipulate the component myunion from the CE.
Setting path to be /myaddress/ip or /myaddress/ip6 is reasona= ble. And you can
play small tricks to let someone use /myad= dress as a path (but thats a separate
topic of discussion). We get the ideal use case of unions.
=

The challenge starts showing up when you ha= ve hierachies.
Example:

mystruct =A0blah {
=A0 =A0 =A0 =A0 =A01: myaddress fooaddre= ss
=A0 =A0 =A0 =A0 =A02: uint32 bar
}
=

There is no clean way of getting the path /= blah from the FE
(compare to when blah had no unions). This is because=A0
it is ambigous within /blah/myaddress whether i am referring to=A0=
/blah/myaddress/ip or ip6 when i do the get.
I could construct a query with multiple paths to retrieve /blah
but i am questioning the usefulness of wasting wire-bits and more<= /div>
cpu for encoding/decoding in order to save host-bits (memor= y)
just for the sake of being able to model something like this as= =A0
a union.
Things get worse if i have a t= able whose rows are struct blah
and say i needed to dump a = few table entries.
Note: I left out the direction of CE->FE setting because less= acrobatics
involved (but still inefficient).

Thoughts?

My suggestion is to define things that need to be modelled this
way as structs with /optional constructs.

cheers,
jamal
--20cf307cfcc6afa98a04ddf0f954-- From joel@stevecrocker.com Thu May 30 08:34:17 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536EE21F8952 for ; Thu, 30 May 2013 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2LRYkEYY7Kg for ; Thu, 30 May 2013 08:34:08 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3B13C21F93A3 for ; Thu, 30 May 2013 08:34:02 -0700 (PDT) Received: from dummy.name; Thu, 30 May 2013 15:34:00 +0000 Message-ID: <51A7715A.9060802@stevecrocker.com> Date: Thu, 30 May 2013 11:33:46 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jamal Hadi Salim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" Subject: Re: [forces] on the utility of unions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:34:17 -0000 Thinking about it, you are probably right. Union does not actually usefully solve the problem it aimed at. There is a minor issue that if you use a discriminator plus 2 or more optional fields, then the definition dos not capture the fact that one of the fields must be present. I think that this is a price we can afford to pay. Yours, Joe On 5/30/2013 11:15 AM, Jamal Hadi Salim wrote: > > Without going into a lot of details - this came up as i tried to implement > union support in our code and a private discussion with Evangelos. > I will try to sumarize but it may be a long email ;-> > > Unions look great from a model perspective; they also save memory use on > a machine. > One of the things Evangelos and I initially thought was a great idea was > something like: > > union myaddress { > 1:ipv4address ip > 2:ipv6address ip6 > } > > This looks good. I can now manipulate the component myunion from the CE. > Setting path to be /myaddress/ip or /myaddress/ip6 is reasonable. And > you can > play small tricks to let someone use /myaddress as a path (but thats a > separate > topic of discussion). We get the ideal use case of unions. > > The challenge starts showing up when you have hierachies. > Example: > > mystruct blah { > 1: myaddress fooaddress > 2: uint32 bar > } > > There is no clean way of getting the path /blah from the FE > (compare to when blah had no unions). This is because > it is ambigous within /blah/myaddress whether i am referring to > /blah/myaddress/ip or ip6 when i do the get. > I could construct a query with multiple paths to retrieve /blah > but i am questioning the usefulness of wasting wire-bits and more > cpu for encoding/decoding in order to save host-bits (memory) > just for the sake of being able to model something like this as > a union. > Things get worse if i have a table whose rows are struct blah > and say i needed to dump a few table entries. > Note: I left out the direction of CE->FE setting because less acrobatics > involved (but still inefficient). > > Thoughts? > > My suggestion is to define things that need to be modelled this > way as structs with /optional constructs. > > cheers, > jamal > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Thu May 30 14:41:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9471521F8B07 for ; Thu, 30 May 2013 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDBIHHT17JmA for ; Thu, 30 May 2013 14:41:40 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CDF9521F8AD5 for ; Thu, 30 May 2013 14:41:36 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so610172veb.17 for ; Thu, 30 May 2013 14:41:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/ujdlL/BWG2sEPyK6qPXsfe7Z9SGOaZ17a3H5e3So0I=; b=g1LFzHlfIhaa6NgiUmgg9ou78CSQ4wJx5vdWkiMp/IJaQ5rD46PsLhUNNB0UASxNdF DlwQDXdSrL/fU5mDr7i8rwUBlO0qZgL3mCiRSGOOq7eYYtTXe/wv0X1oxsp3GQfmLQXF aQYQePTGR68M4nqIAvdCutKoSAdkbGP/xizODdFXL4xYLzuV35bVNextMzU9nZg21I6a mFWIQTdgZ7CQhUSD5x1J2GYn4ia+6J7uY7Yfv2epRF1RDkcwMEPygyu81AIIZw7hbHPN 3KHskrOb8wY+IcjrZCGPC/CJzIAHdRW//Kte68yFj2KlLXnuTEK0JLdW8ydOCdcpXwUV geCA== X-Received: by 10.52.19.49 with SMTP id b17mr6094398vde.89.1369950096163; Thu, 30 May 2013 14:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.206.13 with HTTP; Thu, 30 May 2013 14:41:16 -0700 (PDT) In-Reply-To: <51A7715A.9060802@stevecrocker.com> References: <51A7715A.9060802@stevecrocker.com> From: Jamal Hadi Salim Date: Thu, 30 May 2013 17:41:16 -0400 Message-ID: To: Joel Content-Type: multipart/alternative; boundary=bcaec5040894d7c9f904ddf65c5e X-Gm-Message-State: ALoCoQmgfGaENEonIhIZj10+lUhvQ+LXTaJPKQ5MTD5nhSsmn+CM9wfkR1dLhhK2o6f/0Do35O5w Cc: "forces@ietf.org" Subject: Re: [forces] on the utility of unions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:41:41 -0000 --bcaec5040894d7c9f904ddf65c5e Content-Type: text/plain; charset=ISO-8859-1 Joel, Makes sense. cheers, jamal On Thu, May 30, 2013 at 11:33 AM, Joel wrote: > Thinking about it, you are probably right. Union does not actually > usefully solve the problem it aimed at. > There is a minor issue that if you use a discriminator plus 2 or more > optional fields, then the definition dos not capture the fact that one of > the fields must be present. I think that this is a price we can afford to > pay. > > Yours, > Joe > > > On 5/30/2013 11:15 AM, Jamal Hadi Salim wrote: > >> >> Without going into a lot of details - this came up as i tried to implement >> union support in our code and a private discussion with Evangelos. >> I will try to sumarize but it may be a long email ;-> >> >> Unions look great from a model perspective; they also save memory use on >> a machine. >> One of the things Evangelos and I initially thought was a great idea was >> something like: >> >> union myaddress { >> 1:ipv4address ip >> 2:ipv6address ip6 >> } >> >> This looks good. I can now manipulate the component myunion from the CE. >> Setting path to be /myaddress/ip or /myaddress/ip6 is reasonable. And >> you can >> play small tricks to let someone use /myaddress as a path (but thats a >> separate >> topic of discussion). We get the ideal use case of unions. >> >> The challenge starts showing up when you have hierachies. >> Example: >> >> mystruct blah { >> 1: myaddress fooaddress >> 2: uint32 bar >> } >> >> There is no clean way of getting the path /blah from the FE >> (compare to when blah had no unions). This is because >> it is ambigous within /blah/myaddress whether i am referring to >> /blah/myaddress/ip or ip6 when i do the get. >> I could construct a query with multiple paths to retrieve /blah >> but i am questioning the usefulness of wasting wire-bits and more >> cpu for encoding/decoding in order to save host-bits (memory) >> just for the sake of being able to model something like this as >> a union. >> Things get worse if i have a table whose rows are struct blah >> and say i needed to dump a few table entries. >> Note: I left out the direction of CE->FE setting because less acrobatics >> involved (but still inefficient). >> >> Thoughts? >> >> My suggestion is to define things that need to be modelled this >> way as structs with /optional constructs. >> >> cheers, >> jamal >> >> >> ______________________________**_________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/**listinfo/forces >> >> --bcaec5040894d7c9f904ddf65c5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,

Makes sense.

cheers,
jamal


On Thu,= May 30, 2013 at 11:33 AM, Joel <joel@stevecrocker.com> = wrote:
Thinking about it, you are probably right. = =A0Union does not actually usefully solve the problem it aimed at.
There is a minor issue that if you use a discriminator plus 2 or more optio= nal fields, then the definition dos not capture the fact that one of the fi= elds must be present. =A0I think that this is a price we can afford to pay.=

Yours,
Joe


On 5/30/2013 11:15 AM, Jamal Hadi Salim wrote:

Without going into a lot of details - this came up as i tried to implement<= br> union support in our code and a private discussion with Evangelos.
I will try to sumarize but it may be a long email ;->

Unions look great from a model perspective; they also save memory use on a machine.
One of the things Evangelos and I initially thought was a great idea was something like:

union myaddress {
=A0 =A0 =A0 =A0 =A0 1:ipv4address ip
=A0 =A0 =A0 =A0 =A0 2:ipv6address ip6
}

This looks good. I can now manipulate the component myunion from the CE. Setting path to be /myaddress/ip or /myaddress/ip6 is reasonable. And
you can
play small tricks to let someone use /myaddress as a path (but thats a
separate
topic of discussion). We get the ideal use case of unions.

The challenge starts showing up when you have hierachies.
Example:

mystruct =A0blah {
=A0 =A0 =A0 =A0 =A0 1: myaddress fooaddress
=A0 =A0 =A0 =A0 =A0 2: uint32 bar
}

There is no clean way of getting the path /blah from the FE
(compare to when blah had no unions). This is because
it is ambigous within /blah/myaddress whether i am referring to
/blah/myaddress/ip or ip6 when i do the get.
I could construct a query with multiple paths to retrieve /blah
but i am questioning the usefulness of wasting wire-bits and more
cpu for encoding/decoding in order to save host-bits (memory)
just for the sake of being able to model something like this as
a union.
Things get worse if i have a table whose rows are struct blah
and say i needed to dump a few table entries.
Note: I left out the direction of CE->FE setting because less acrobatics=
involved (but still inefficient).

Thoughts?

My suggestion is to define things that need to be modelled this
way as structs with /optional constructs.

cheers,
jamal


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


--bcaec5040894d7c9f904ddf65c5e-- From adrian@olddog.co.uk Thu May 30 19:22:35 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7421F994F for ; Thu, 30 May 2013 19:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjQWGJgd4Scb for ; Thu, 30 May 2013 19:22:25 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 3713921F910D for ; Thu, 30 May 2013 19:22:23 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4V2MLku006398; Fri, 31 May 2013 03:22:22 +0100 Received: from 950129200 (HKRnf12760.tokyo-ip.dti.ne.jp [27.120.235.10]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4V2MHhF006373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 May 2013 03:22:19 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" , "'Joel'" References: <51A7715A.9060802@stevecrocker.com> In-Reply-To: Date: Fri, 31 May 2013 03:22:13 +0100 Message-ID: <026b01ce5da5$ac15a610$0440f230$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026C_01CE5DAE.0DDEA1F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5mf+3odI1B7IZp9KKgHNvDZiBgAJzGw6cAnJnoSqYIOrtEA== Content-Language: en-gb Cc: forces@ietf.org Subject: Re: [forces] on the utility of unions X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 31 May 2013 02:22:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_026C_01CE5DAE.0DDEA1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just for the hell of it... Currently very sleep deprived and catching up with the ForCES list I came across this thread with subject line "on the utility of unicorns" Thanks for that :-) Adrian From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: 30 May 2013 22:41 To: Joel Cc: forces@ietf.org Subject: Re: [forces] on the utility of unions Joel, Makes sense. cheers, jamal On Thu, May 30, 2013 at 11:33 AM, Joel wrote: Thinking about it, you are probably right. Union does not actually usefully solve the problem it aimed at. There is a minor issue that if you use a discriminator plus 2 or more optional fields, then the definition dos not capture the fact that one of the fields must be present. I think that this is a price we can afford to pay. Yours, Joe On 5/30/2013 11:15 AM, Jamal Hadi Salim wrote: Without going into a lot of details - this came up as i tried to implement union support in our code and a private discussion with Evangelos. I will try to sumarize but it may be a long email ;-> Unions look great from a model perspective; they also save memory use on a machine. One of the things Evangelos and I initially thought was a great idea was something like: union myaddress { 1:ipv4address ip 2:ipv6address ip6 } This looks good. I can now manipulate the component myunion from the CE. Setting path to be /myaddress/ip or /myaddress/ip6 is reasonable. And you can play small tricks to let someone use /myaddress as a path (but thats a separate topic of discussion). We get the ideal use case of unions. The challenge starts showing up when you have hierachies. Example: mystruct blah { 1: myaddress fooaddress 2: uint32 bar } There is no clean way of getting the path /blah from the FE (compare to when blah had no unions). This is because it is ambigous within /blah/myaddress whether i am referring to /blah/myaddress/ip or ip6 when i do the get. I could construct a query with multiple paths to retrieve /blah but i am questioning the usefulness of wasting wire-bits and more cpu for encoding/decoding in order to save host-bits (memory) just for the sake of being able to model something like this as a union. Things get worse if i have a table whose rows are struct blah and say i needed to dump a few table entries. Note: I left out the direction of CE->FE setting because less acrobatics involved (but still inefficient). Thoughts? My suggestion is to define things that need to be modelled this way as structs with /optional constructs. cheers, jamal _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces ------=_NextPart_000_026C_01CE5DAE.0DDEA1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just for the hell of = it...

 

Currently very sleep deprived = and catching up with the ForCES list I came across this thread with = subject line "on the utility of = unicorns"

 

Thanks for that = :-)

 

Adrian

 

From: = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = Jamal Hadi Salim
Sent: 30 May 2013 22:41
To: = Joel
Cc: forces@ietf.org
Subject: Re: [forces] on = the utility of unions

 

Joel,

 

Makes sense.

 

cheers,

jamal

 

On Thu, May 30, 2013 at 11:33 AM, Joel <joel@stevecrocker.com> wrote:

Thinking about it, you are probably right.  Union = does not actually usefully solve the problem it aimed at.
There is a = minor issue that if you use a discriminator plus 2 or more optional = fields, then the definition dos not capture the fact that one of the = fields must be present.  I think that this is a price we can afford = to pay.

Yours,
Joe



On 5/30/2013 11:15 AM, Jamal Hadi Salim = wrote:


Without going into a lot of details - = this came up as i tried to implement
union support in our code and a = private discussion with Evangelos.
I will try to sumarize but it may = be a long email ;->

Unions look great from a model = perspective; they also save memory use on
a machine.
One of the = things Evangelos and I initially thought was a great idea = was
something like:

union myaddress {
      =     1:ipv4address ip
          = 2:ipv6address ip6
}

This looks good. I can now manipulate the = component myunion from the CE.
Setting path to be /myaddress/ip or = /myaddress/ip6 is reasonable. And
you can
play small tricks to let = someone use /myaddress as a path (but thats a
separate
topic of = discussion). We get the ideal use case of unions.

The challenge = starts showing up when you have hierachies.
Example:

mystruct =  blah {
          1: myaddress = fooaddress
          2: uint32 = bar
}

There is no clean way of getting the path /blah from the = FE
(compare to when blah had no unions). This is because
it is = ambigous within /blah/myaddress whether i am referring = to
/blah/myaddress/ip or ip6 when i do the get.
I could construct = a query with multiple paths to retrieve /blah
but i am questioning = the usefulness of wasting wire-bits and more
cpu for = encoding/decoding in order to save host-bits (memory)
just for the = sake of being able to model something like this as
a union.
Things = get worse if i have a table whose rows are struct blah
and say i = needed to dump a few table entries.
Note: I left out the direction of = CE->FE setting because less acrobatics
involved (but still = inefficient).

Thoughts?

My suggestion is to define things = that need to be modelled this
way as structs with /optional = constructs.

cheers,
jamal

__________________________________________= _____
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces

 

------=_NextPart_000_026C_01CE5DAE.0DDEA1F0--