From ehalep@gmail.com Mon Oct 1 15:06:05 2012 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 BD84E11E815A for ; Mon, 1 Oct 2012 15:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YmZu+JkQHiM for ; Mon, 1 Oct 2012 15:06:05 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C209311E809A for ; Mon, 1 Oct 2012 15:06:04 -0700 (PDT) Received: by weyu46 with SMTP id u46so3535144wey.31 for ; Mon, 01 Oct 2012 15:06:04 -0700 (PDT) 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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=BUG31j4sOTgb21bPlOD2n/jQkPOCtVR7bqoaFDUFbn8=; b=jnel0hzY6+7b9WJj8Cad6u/Wrg7gQjs1/P0q6HZ0ixguF2jdHgovj+/UYrTfVXwg9w onQO2ssm6woTKP5J9g5hzTMF9BJB7I6R3lXcqM5BGBH8qleD38oDNfmb9abujGhLZPUt xJgZLtBOtw4JYApEl9+4fp6YSuGryTY+LbXmn7l+JMVCs49OUz+phdsBkoNiMLcZ5wK1 bZpRmwLL5a4c4zi1m/UjvLnmZAZeT/KX8JD2wmQxTfM2Y1aAkembo6J5ESKLtn95PnZB U65bDDSRa9RPZ8jqdfYv3ccqbnaaWsCPkrikvMc6e1lxG1huX/KmCkjbKu1rrFBVBQUE xBXQ== Received: by 10.180.101.230 with SMTP id fj6mr12438322wib.16.1349129163911; Mon, 01 Oct 2012 15:06:03 -0700 (PDT) Received: from EhalepXPS (ppp141237244129.access.hol.gr. [141.237.244.129]) by mx.google.com with ESMTPS id w7sm18505104wiz.0.2012.10.01.15.06.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 15:06:03 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Tue, 2 Oct 2012 01:06:00 +0300 Message-ID: <00ec01cda020$f1d0e810$d572b830$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2gHdh67kSbs3YPSzGBdarYa2w8ZwAAOj1A Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Mon, 01 Oct 2012 22:06:05 -0000 Greetings to the list, This draft describes some extensions in the model schema of the LFB = library based mostly on the experience of the openflow library. Comments and suggestions are more than welcome. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, October 02, 2012 12:37 AM > To: ehalep@ece.upatras.gr > Subject: New Version Notification for draft-haleplidis-forces-model- > extension-00.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-model-extension-00.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-model-extension > Revision: 00 > Title: ForCES Model Extension > Creation date: 2012-10-01 > WG ID: Individual Submission > Number of pages: 19 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-model-extensi= on-00.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-model-extension > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-model-extension-00 >=20 >=20 > 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. >=20 > RFC5812 has been around for two years and experience in its use has > shown room for extensions without a need to alter the protocol = while > retaining backward compatibility with older xml libraries. >=20 >=20 >=20 >=20 > The IETF Secretariat From hadi@mojatatu.com Tue Oct 2 03:11:14 2012 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 EC7C921F8ACA for ; Tue, 2 Oct 2012 03:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4DPealChru5 for ; Tue, 2 Oct 2012 03:11:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9B3221F8A28 for ; Tue, 2 Oct 2012 03:11:09 -0700 (PDT) Received: by obqv19 with SMTP id v19so7164042obq.31 for ; Tue, 02 Oct 2012 03:11:09 -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=xdBlJmHKJSMkdwO5pskoGfQ9v9+rgP0A9/ARfPUf3jw=; b=RvS/FWJMMGvtTQ0GiBG7YrUTDikvGRI+i9WUNi7BMIIqHAP2nbXzSic1tYnxvM3Re4 BMUiJRKPuqgL4lYkOu5lQRprJ9ehwf+OcmlygxAJHjgk2xVU3n+Fa+ChlszREW4VjVeE VnYpK11h3jqKah5xL0Ekr55ZYtPAXFrZ9k6hGsEbuIyWSWj0k0C7y9cNLRNWPeOIQ4cI RJOQz1uSe3HyCkmd1ldjDGVl9H33+6D+Dkn5FkIQ5CPdrtd2RtlWppi6S0FXnWMqJD5C l9D8Pq+TydDvgPhDAaixmdSzwsgQk0DeTmLm3Kbg6A+Sb63i68fFtQ/xyorKngwRHHZa /U7w== Received: by 10.60.20.74 with SMTP id l10mr13593688oee.19.1349172669366; Tue, 02 Oct 2012 03:11:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.92.129 with HTTP; Tue, 2 Oct 2012 03:10:49 -0700 (PDT) In-Reply-To: <00ec01cda020$f1d0e810$d572b830$@com> References: <00ec01cda020$f1d0e810$d572b830$@com> From: Jamal Hadi Salim Date: Tue, 2 Oct 2012 06:10:49 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm/doqy3f2hxPKIE0ibNfPu75Xds/z1Ouy0GpDhXWau8Odm0EueZSj2iEtohXl4XyElBqaI Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Tue, 02 Oct 2012 10:11:15 -0000 Greetings Evangelos, My comments: 1) On Complex Metadata I think this is a useful extension. Can you be more precise as to what in OF uses complex metadata? 2) DataType and Metadata Optional Default Value I am not clear on this one. We can define default values on per component level. If the component is a complex, this rule still applies to all individual scalar components within the complex component. What is missing? 3) Optional Frame Produced This sounds to me like an errata. We allow input to be a packet and/or metadata. We also allow output to be a packet and/or metadata. If you can point to which text in 5812 implies that an output MUST have packet data, then an errata would seem reasonable. 4) Strengthening the XML Some of these things in our implementation are taken care of by our own tools because they are common sense (having the same ID for different things is one) and none of the other ones are a problem in real life; the only ones we cant catch span multiple xml files (since we dont keep state); having said that i can see that it would be useful for the schema to catch things when possible at XML validation time. Question: Did you actually test the xml changes against the different error use cases? General comment: I think it would be useful for each use case section to show the accompanying xml change piece and then have one large section with all the changes. RFC 5812 illustrates this approach. cheers, jamal From ehalep@gmail.com Tue Oct 2 04:08:10 2012 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 1FAA221F8B14 for ; Tue, 2 Oct 2012 04:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvPd8xa-a8+f for ; Tue, 2 Oct 2012 04:08:09 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F061721F8B16 for ; Tue, 2 Oct 2012 04:08:08 -0700 (PDT) Received: by eekd4 with SMTP id d4so3171521eek.31 for ; Tue, 02 Oct 2012 04:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=pSrqYxvbW5Uzz440ZrlHFtRfUw/i5TGkJCDNsajSD1k=; b=LN9LQ1G8EfAmlalNkMcdii/Uw5j5CvHhoAj3lqhI354n/Nvkgympe2GfbmH7bo/75I jPJcLdvx59uAZe2L+dVW3K6wYmvj+1h++VZFNfOMVY6rdnipNgHEXTNklmzGV8WHTHQ5 v4opqM7QJswzzvWw01iox0YD8n37mJUc42dtJ3fUUzWjE+d8tghEnu1OeIAIWZxwiMTZ eAAOMxEvgzMFliHD7M8uqULCSPUmyVQTFtiB2mOGYkeka65U5PFAIltbqZw4GnXnNrn9 8B1nkvkKX9jznr9uwJ+Dz7zVWVXBIYxhuTJbY4+bjbUKiLzQgUTw0DsbRpO+BP0HZHXs ZzaA== Received: by 10.14.173.9 with SMTP id u9mr21562243eel.8.1349176088084; Tue, 02 Oct 2012 04:08:08 -0700 (PDT) Received: from EhalepXPS (ppp141237022184.access.hol.gr. [141.237.22.184]) by mx.google.com with ESMTPS id x42sm70274eel.11.2012.10.02.04.08.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 04:08:07 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ec01cda020$f1d0e810$d572b830$@com> In-Reply-To: Date: Tue, 2 Oct 2012 14:08:03 +0300 Message-ID: <00a901cda08e$32af4580$980dd080$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2ghj/LiWbEgDOjSleHxr+POO7wNQAANIwg Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Tue, 02 Oct 2012 11:08:10 -0000 Greetings Jamal, Thanks for the comments. Please see inline. Regards, Evangelos Haleplidis. > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Tuesday, October 02, 2012 1:11 PM > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] FW: New Version Notification for draft- > haleplidis-forces-model-extension-00.txt >=20 > Greetings Evangelos, >=20 > My comments: >=20 > 1) On Complex Metadata > I think this is a useful extension. Can you be more precise as to what > in OF uses complex metadata? >=20 [=C5=C7] From my understanding, OF uses complex metadata in two separate occasions: 1. The ActionSet metadata, which is a list of actions to be performed at = the end of the pipeline. 2. When a packet is received from a controller it may be accompanied by = a list of actions to be performed on it prior to be sent on the flow table pipeline. > 2) DataType and Metadata Optional Default Value >=20 > I am not clear on this one. > We can define default values on per component level. > If the component is a complex, this rule still applies to all > individual scalar components within the complex component. > What is missing? [=C5=C7] Take for example the FlowTables component in the OFFlowTables. It's an array, with each row a struct of { FlowEntries (array) FlowTableCounter (struct) MissBehaviour (atomic) } Now, the FlowTableCounter is struct of{ ReferenceCount (uint32) PacketLookups (uint64) PacketMatches (uint64) } Now, with the current schema, if I wanted to add a default value of 0 to = the counters, the only place I can add a default value is at the top level = of the FlowTables component (meaning the initial array of FlowEntries etc). This means that I must set default values for all components. I cannot individually set each or all counters to 0. Additionally, in the current OF-lib definition the FlowTableCounters is = a struct of a pre-defined datatype called TableCounterType, specified in = the dataTypeDef sections (and a struct also). I am unable to set these = default values. With the model extension, it is possible to provide optional default = values both in the datatype definitions, and also inside complex data types. >=20 > 3) Optional Frame Produced > This sounds to me like an errata. > We allow input to be a packet and/or metadata. > We also allow output to be a packet and/or metadata. > If you can point to which text in 5812 implies that an output MUST = have > packet data, then an errata would seem reasonable. >=20 [=C5=C7] Basically it is enforced by the xml schema. The text in section "3.2.1 LFB Outputs" in page 18 defines it clearly: " The information sent on that port is a pair of a packet and associated metadata, one of which may be empty. (If both were empty, there would be no output.)" But in section " 4.7.3. Element to Define LFB Outputs" it = says: " The element MUST contain the following elements:" ... " lists the allowed frame formats."=20 ...=20 " The element MAY also contain the list of emitted (generated) metadata." In a very strict approach, we could change one of the text above to " MAY lists the allowed frame formats." > 4) Strengthening the XML > Some of these things in our implementation are taken care of by our = own > tools because they are common sense (having the same ID for different > things is one) and none of the other ones are a problem in real life; > the only ones we cant catch span multiple xml files (since we dont = keep > state); having said that i can see that it would be useful for the > schema to catch things when possible at XML validation time. Question: > Did you actually test the xml changes against the different error use > cases? >=20 [=C5=C7] Yes. And they work fine - of course the same applies here. The = xml validation defined in this draft occurs only in a single xml file, not = in multiple. > General comment: > I think it would be useful for each use case section to show the > accompanying xml change piece and then have one large section with all > the changes. RFC 5812 illustrates this approach. >=20 [=C5=C7] Good idea, thanks. Will do that in the next revision. > cheers, > jamal From hadi@mojatatu.com Tue Oct 2 04:30:24 2012 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 DFC7421F8A85 for ; Tue, 2 Oct 2012 04:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxHqNa9Ham3G for ; Tue, 2 Oct 2012 04:30:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 472BE21F8A84 for ; Tue, 2 Oct 2012 04:30:24 -0700 (PDT) Received: by obqv19 with SMTP id v19so7229636obq.31 for ; Tue, 02 Oct 2012 04:30:23 -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:content-transfer-encoding:x-gm-message-state; bh=fq/PwH2ZuMa7Cv4yJZAveExzzcly5EhwQPSwOIMV9aI=; b=bw9cR5yXl82US3CD1J5FMI4r91eQNSMtsTChzpzxSb58NRQuz6/GOCzb60zROBz+BJ eVCB0y2tZ3Cnd6Omk4n5+vHuzdqneo19mFt3I/86/QQisfXZFIAhNfkA/8RO2SNJ6lKR hoNyBm1RfY63c91vfCZ4uQio6VZFF8M5gakYyl3uvqJU5A1BsaPrqdGyX2JXjrQV/uRu ZBrVgLher55U8kpNDfWMbUDDaUNXntynwmthNTY1Fl8SSQYJmQRB87Moj+WLdAUTVIZD cK7jFRGn5iyaW5C2sCu9Q2ZDTJH1yt5hNbFl5qbwoArYEqn2iTfsziFGFMsVQq0JTZ9t o15w== Received: by 10.60.25.106 with SMTP id b10mr11649056oeg.7.1349177423781; Tue, 02 Oct 2012 04:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.92.129 with HTTP; Tue, 2 Oct 2012 04:30:03 -0700 (PDT) In-Reply-To: <00a901cda08e$32af4580$980dd080$@com> References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> From: Jamal Hadi Salim Date: Tue, 2 Oct 2012 07:30:03 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlrefgPXmNOl/q3thrgx0WIk4X4sUbP6R/bzKmpmfe0XlHGY0edjx4s27yBQUtcos6Ds1YM Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Tue, 02 Oct 2012 11:30:25 -0000 On Tue, Oct 2, 2012 at 7:08 AM, Haleplidis Evangelos wro= te: > [=C5=C7] From my understanding, OF uses complex metadata in two separate > occasions: > 1. The ActionSet metadata, which is a list of actions to be performed at = the > end of the pipeline. > 2. When a packet is received from a controller it may be accompanied by a > list of actions to be performed on it prior to be sent on the flow table > pipeline. Ok, makes sense. Can you please provide such illustrative text when you update the draft? > [=C5=C7] Take for example the FlowTables component in the OFFlowTables. > It's an array, with each row a struct of { > FlowEntries (array) > FlowTableCounter (struct) > MissBehaviour (atomic) > } > > Now, the FlowTableCounter is struct of{ > ReferenceCount (uint32) > PacketLookups (uint64) > PacketMatches (uint64) > } > > Now, with the current schema, if I wanted to add a default value of 0 to = the > counters, the only place I can add a default value is at the top level of > the FlowTables component (meaning the initial array of FlowEntries etc). Did you mean the only place you can set the defaults is in FlowTableCounte= r definition? > This means that I must set default values for all components. I cannot > individually set each or all counters to 0. So i can see one use case where this would make sense. not sure if this is what you are referencing above: Example if i used struct FlowTableCounter in multiple places and wanted different default values (example in ref1 i wanted all fields to have a def= ault of 0 and in ref2 of FlowTableCounter wanted a default of 1). > Additionally, in the current OF-lib definition the FlowTableCounters is a > struct of a pre-defined datatype called TableCounterType, specified in th= e > dataTypeDef sections (and a struct also). I am unable to set these defaul= t > values. > > With the model extension, it is possible to provide optional default valu= es > both in the datatype definitions, and also inside complex data types. > I think this is possibly what I was talking about above? > [=C5=C7] Basically it is enforced by the xml schema. > The text in section "3.2.1 LFB Outputs" in page 18 defines it clearly: > > " The information sent on that port is a > pair of a packet and associated metadata, one of which may be empty. > (If both were empty, there would be no output.)" > > But in section " 4.7.3. Element to Define LFB Outputs" it sa= ys: > > " The element MUST contain the following elements:" > ... > " lists the allowed frame formats." > ... > " The element MAY also > contain the list of emitted (generated) metadata." > > In a very strict approach, we could change one of the text above to > " MAY lists the allowed frame formats." > I dont think there was any intent in creating some magical packet data output even when none existed. Ok, definitely an errata. Joel? > [=C5=C7] Yes. And they work fine - of course the same applies here. The x= ml > validation defined in this draft occurs only in a single xml file, not in > multiple. If you have tested them - can you please annotate which ones require that you have multiple LFB definitions in one XML file and which ones will catch issues regardless. I know for example that metadata IDs are global and would require IANA involvement - so likelihood of conflict is small. cheers, jamal From hadi@mojatatu.com Tue Oct 2 04:31:52 2012 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 4C63021F8A8F for ; Tue, 2 Oct 2012 04:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93PUAVmsB5hT for ; Tue, 2 Oct 2012 04:31:51 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5E8421F8A8E for ; Tue, 2 Oct 2012 04:31:51 -0700 (PDT) Received: by oagn5 with SMTP id n5so7351955oag.31 for ; Tue, 02 Oct 2012 04:31:51 -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=UB1wdfHXfsCXOV5JC+hHA4XiMjWPF/ECT9A6zYy1rQU=; b=YAY1d0O3vmrzLjkHJg/lkY8z2MjT2kep8sEcf3Cc/4wazcFnx7x9G9oB27kw27pOz6 gj5zKU+HY9crdVtDw+QH5yiLXjKR90PqwJ6BPEovh5M0W2LjuENWPo5kjEgw7OYaqjlp mh6rfRrYlC4g+nksGPFUmr5eUSLdm0Pft0MqHA8klXWKJ48taOq/NJwustucRRjsRXxC uZNGF6NJhAIrKO0xx6k6wvKP9k2q1eWhvJowK775hq+tCAO+f/wOO3axwr84KSEmeyjZ H8M2TAST8NVZvqInRafzZ/oMlc7yM9hD1XniFKJwzFeMUpaZ3lfVFcq6jVJID7xktpbi akQQ== Received: by 10.60.20.8 with SMTP id j8mr13718555oee.127.1349177511266; Tue, 02 Oct 2012 04:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.92.129 with HTTP; Tue, 2 Oct 2012 04:31:31 -0700 (PDT) In-Reply-To: References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> From: Jamal Hadi Salim Date: Tue, 2 Oct 2012 07:31:31 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnjv3AQmhN094pvg4O/nK3u4BzTengwobSYdDN6I8nSYuRTpVT4rRopiBA1hCd1x9OllElI Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Tue, 02 Oct 2012 11:31:52 -0000 On Tue, Oct 2, 2012 at 7:30 AM, Jamal Hadi Salim wrote: > > If you have tested them - can you please annotate which ones require that > you have multiple LFB definitions in one XML file and which ones will catch > issues regardless. > I know for example that metadata IDs are global and would require IANA > involvement - so likelihood of conflict is small. I will also make the point that these are enhancements as opposed to extensions and that section should be labelled as such in the draft text. cheers, jamal From joel@stevecrocker.com Tue Oct 2 06:19:03 2012 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 5EE2E21F846B for ; Tue, 2 Oct 2012 06:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExzrAI7iSI7f for ; Tue, 2 Oct 2012 06:19:03 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9A21F845A for ; Tue, 2 Oct 2012 06:19:02 -0700 (PDT) Received: from [71.161.51.10] (account joel@stevecrocker.com HELO [10.10.10.104]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 20867541; Tue, 02 Oct 2012 13:19:51 +0000 Message-ID: <506AE9C2.5070805@stevecrocker.com> Date: Tue, 02 Oct 2012 09:18:58 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jamal Hadi Salim References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Tue, 02 Oct 2012 13:19:03 -0000 I agree, the text in 4.7.3 is too strict. Our intention was as stated in 3.2.1. An errata works for me. Yours, Joel On 10/2/2012 7:30 AM, Jamal Hadi Salim wrote: >> >[ลว] Basically it is enforced by the xml schema. >> >The text in section "3.2.1 LFB Outputs" in page 18 defines it clearly: >> > >> >" The information sent on that port is a >> > pair of a packet and associated metadata, one of which may be empty. >> > (If both were empty, there would be no output.)" >> > >> >But in section " 4.7.3. Element to Define LFB Outputs" it says: >> > >> >" The element MUST contain the following elements:" >> >... >> >" lists the allowed frame formats." >> >... >> >" The element MAY also >> > contain the list of emitted (generated) metadata." >> > >> >In a very strict approach, we could change one of the text above to >> >" MAY lists the allowed frame formats." >> > > I dont think there was any intent in creating some magical packet data > output even when none existed. > Ok, definitely an errata. Joel? > From ehalep@gmail.com Tue Oct 2 14:43:20 2012 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 8DD6121F8618 for ; Tue, 2 Oct 2012 14:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oX1kXaKk-Yd for ; Tue, 2 Oct 2012 14:43:19 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1444121F8615 for ; Tue, 2 Oct 2012 14:43:18 -0700 (PDT) Received: by weyu46 with SMTP id u46so4273221wey.31 for ; Tue, 02 Oct 2012 14:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=P5HGCQa0SmVvGo0HGkGLAuJSxnigoEMWdCZb+O7rTgs=; b=ZPmlbbUgjE+yjeRQMBAsKgXZsqpjgVHS9EgpJUQJpMp89rOLyAFkfz8CsLBk0qvKK2 hQOzqJuUAlTXqInQsTvZq2F+Wd23wM9bNfKmnB8xxuba7YksB2b33SUwzY1sGzsZMOCC RpKbJnaxyuZy96haKJDMckUcEYvsepFVdLplJGSFks7Mvk9MWhJeyhY4HoYSqPsKUXc2 rJxhj5ajrZ0xBZSl2DkkvffehfKlc2iQA4RGaqmNtrK047E0UfhYJMT2U1RQGDdOeWpX PcoOT/f/Qs6A6l16EO95nKVDDs0Sp1/ROPOZ24ocEvGtaFv1loFQb7PS3ZHK+fVjD3b3 giBg== Received: by 10.180.94.226 with SMTP id df2mr24761580wib.11.1349214197513; Tue, 02 Oct 2012 14:43:17 -0700 (PDT) Received: from EhalepXPS (ppp141237022184.access.hol.gr. [141.237.22.184]) by mx.google.com with ESMTPS id hv8sm27771554wib.0.2012.10.02.14.43.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 14:43:16 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> In-Reply-To: Date: Wed, 3 Oct 2012 00:43:12 +0300 Message-ID: <010701cda0e6$ed5ed5f0$c81c81d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2gkkZgnGFnTiaLSkO7ciCMPPugzgAUu8gw Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Tue, 02 Oct 2012 21:43:20 -0000 Greetings Jamal, Please see inline. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Tuesday, October 02, 2012 2:30 PM > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] FW: New Version Notification for draft- > haleplidis-forces-model-extension-00.txt >=20 > On Tue, Oct 2, 2012 at 7:08 AM, Haleplidis Evangelos = > wrote: >=20 > > [=C5=C7] From my understanding, OF uses complex metadata in two = separate > > occasions: > > 1. The ActionSet metadata, which is a list of actions to be = performed > > at the end of the pipeline. > > 2. When a packet is received from a controller it may be accompanied > > by a list of actions to be performed on it prior to be sent on the > > flow table pipeline. >=20 > Ok, makes sense. Can you please provide such illustrative text when = you > update the draft? >=20 > > [=C5=C7] Take for example the FlowTables component in the = OFFlowTables. > > It's an array, with each row a struct of { > > FlowEntries (array) > > FlowTableCounter (struct) > > MissBehaviour (atomic) > > } > > > > Now, the FlowTableCounter is struct of{ > > ReferenceCount (uint32) > > PacketLookups (uint64) > > PacketMatches (uint64) > > } > > > > Now, with the current schema, if I wanted to add a default value of = 0 > > to the counters, the only place I can add a default value is at the > > top level of the FlowTables component (meaning the initial array of > FlowEntries etc). >=20 > Did you mean the only place you can set the defaults is in > FlowTableCounter definition? >=20 [=C5=C7] No, the only place I can set the default value is at the = FlowTables component level. I can't set it at the FlowTableCounter definition. Like this: FlowTables Array{ struct of { FlowEntries (array) FlowTableCounter (struct) MissBehaviour (atomic) } } Default value of FlowTables =3D ... > > This means that I must set default values for all components. I > cannot > > individually set each or all counters to 0. >=20 > So i can see one use case where this would make sense. not sure if = this > is what you are referencing above: > Example if i used struct FlowTableCounter in multiple places and = wanted > different default values (example in ref1 i wanted all fields to have = a > default of 0 and in ref2 of FlowTableCounter wanted a default of 1). >=20 [=C5=C7] That's one use case. > > Additionally, in the current OF-lib definition the FlowTableCounters > > is a struct of a pre-defined datatype called TableCounterType, > > specified in the dataTypeDef sections (and a struct also). I am > unable > > to set these default values. > > > > With the model extension, it is possible to provide optional default > > values both in the datatype definitions, and also inside complex = data > types. > > >=20 > I think this is possibly what I was talking about above? >=20 [=C5=C7] No. What I meant, is that when you define a dataTypeDef, you = can assign optional default value for the datatype. Therefore if you define a = counter datatype, you can set a default value of zero, without having to set it multiple times if you use it multiple times in an LFB definition. However, in order to avoid ambiguity, the text specifies that if a = default value is added later in a component definition of an LFB, then the = default value in the component definition takes precedence. Additionally, this extension allows default values in metadata as well. > > [=C5=C7] Basically it is enforced by the xml schema. > > The text in section "3.2.1 LFB Outputs" in page 18 defines it > clearly: > > > > " The information sent on that port is a > > pair of a packet and associated metadata, one of which may be > empty. > > (If both were empty, there would be no output.)" > > > > But in section " 4.7.3. Element to Define LFB Outputs" > it says: > > > > " The element MUST contain the following elements:" > > ... > > " lists the allowed frame formats." > > ... > > " The element MAY also > > contain the list of emitted (generated) metadata." > > > > In a very strict approach, we could change one of the text above to > > " MAY lists the allowed frame formats." > > >=20 > I dont think there was any intent in creating some magical packet data > output even when none existed. > Ok, definitely an errata. Joel? >=20 [=C5=C7] Besides the need to change the text, we need also change the = schema to make it optional, since the schema enforces that as well. > > [=C5=C7] Yes. And they work fine - of course the same applies here. = The > > xml validation defined in this draft occurs only in a single xml > file, > > not in multiple. >=20 > If you have tested them - can you please annotate which ones require > that you have multiple LFB definitions in one XML file and which ones > will catch issues regardless. > I know for example that metadata IDs are global and would require IANA > involvement - so likelihood of conflict is small. >=20 [=C5=C7] The current schema validation unfortunately occurs within one = single XML file.=20 > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Wed Oct 3 03:50:08 2012 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 212EC21F86C7 for ; Wed, 3 Oct 2012 03:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCYXmYh+gZ1t for ; Wed, 3 Oct 2012 03:50:07 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C33F21F86C3 for ; Wed, 3 Oct 2012 03:50:07 -0700 (PDT) Received: by oagn5 with SMTP id n5so8707763oag.31 for ; Wed, 03 Oct 2012 03:50:03 -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:content-transfer-encoding:x-gm-message-state; bh=YL4+ZSuW0BJn7c2GtkO4e75l99jrenNnOqFam71yHx0=; b=bWsbWpDGAo/c+TZgsIOiuihsk08nLaMMXOsjR0VDmzfw9rrjbC7rTmPw7Bixnfp2P9 QoM/b0PZgGsZlH1LaKtt89DUm2fWhulQgex2E3MY/cvudY2s7LS5t+bsIrxOkPDyldCB n0LjBFcqd6mwZdQK1d1SSnjQc3oBU50sMzjWP4CVUtXp6m2Cm9AJ65gktEKsfOfzkXoi bhMSb+JC0+wea/Cp7Fw0KN2SlxtcTXrOkIOgmUJN4aXdPozCZIgltD/V6pK5Uew6cBS3 I9abOVr/Lb5SezypX4iJfSL9VNzYIIFyvsKlcJWT/9hEeStE+jjk9dl2M+QoHFSALI0P vrsw== Received: by 10.60.30.229 with SMTP id v5mr1095468oeh.130.1349261403026; Wed, 03 Oct 2012 03:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.92.129 with HTTP; Wed, 3 Oct 2012 03:49:42 -0700 (PDT) In-Reply-To: <010701cda0e6$ed5ed5f0$c81c81d0$@com> References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> From: Jamal Hadi Salim Date: Wed, 3 Oct 2012 06:49:42 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl3YMrTduwZBjZCv5NaT0k0J+jseC8l/BfZYgDmULpskaeBQfG4rTMGgsYg7MvpfGjka5Ue Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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, 03 Oct 2012 10:50:08 -0000 Greetings Evangelos, On Tue, Oct 2, 2012 at 5:43 PM, Haleplidis Evangelos wro= te: > Greetings Jamal, > [=C5=C7] No, the only place I can set the default value is at the FlowTab= les > component level. I can't set it at the FlowTableCounter definition. Like > this: > FlowTables > Array{ > struct of { > FlowEntries (array) > FlowTableCounter (struct) > MissBehaviour (atomic) > } > } > Default value of FlowTables =3D ... That will look weird and i am not sure how youd write it out in the xml. But i take it you can do this because components can have default values and the FlowTables is a component. I guess i am struggling to see the relevance of this specific use case. You could specify the the counters to be zero at the datatype definition of Flow counter and solve your problem. >> So i can see one use case where this would make sense. not sure if this >> is what you are referencing above: >> Example if i used struct FlowTableCounter in multiple places and wanted >> different default values (example in ref1 i wanted all fields to have a >> default of 0 and in ref2 of FlowTableCounter wanted a default of 1). >> > > [=C5=C7] That's one use case. And it can specify things at LFB component level now i realize i can solve my problem here as well (so i dont need any schema extension). > [=C5=C7] No. What I meant, is that when you define a dataTypeDef, you can= assign > optional default value for the datatype. Therefore if you define a counte= r > datatype, you can set a default value of zero, without having to set it > multiple times if you use it multiple times in an LFB definition. > However, in order to avoid ambiguity, the text specifies that if a defaul= t > value is added later in a component definition of an LFB, then the defaul= t > value in the component definition takes precedence. Which makes sense. > Additionally, this extension allows default values in metadata as well. We can already have default value in metadata I believe. I think the only ugly thing that seems to stick out at this point is the way you would define things for something as deeply nested as the FlowTables. > [=C5=C7] Besides the need to change the text, we need also change the sch= ema to > make it optional, since the schema enforces that as well. Ok. Please prepare the errata. > [=C5=C7] The current schema validation unfortunately occurs within one si= ngle > XML file. Which is fine; just need to highlight that fact. cheers, jamal From ehalep@gmail.com Thu Oct 4 06:18:13 2012 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 328C121F86B8 for ; Thu, 4 Oct 2012 06:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNCzKZtqY+fD for ; Thu, 4 Oct 2012 06:18:12 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0421F86B6 for ; Thu, 4 Oct 2012 06:18:11 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so3357853wib.13 for ; Thu, 04 Oct 2012 06:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=TtAQHz1fqRr3b6yb6wvkRQPXsuPUzVO6ChkEhda4Evo=; b=agK095wxyxOJQVhbSrhrPEQUW3ANbv4xnvGMlprJlKQ/wSB/ccMfy3q0wpKJo54wlB gR0LruCCLgCLc/NnA2dhhPkBxUJS/8gCxxRFOkUW+qpwIVNxIF5DPKnLAWpCkEDhfF0G F3/GZGS/a/nXQwUa57/vyBJz6eX/IK8RFRk/5avP6dO2kNEzJOxJX3A0HXuyeNhQIyHy HKucEeOBaW0dX7FDu3gRQtyEEFGRvaksvYIVJQ43KvWqO4Kf6QuAx+UTH7h3fiqCmCYD BhCUQndr0l1cX9KK6DzYDTaAQoCxQ1wEvVG9HMl4N5uXARjgAoXuAQjRPug9SOT8afIC GHdw== Received: by 10.180.87.74 with SMTP id v10mr12914987wiz.21.1349356691015; Thu, 04 Oct 2012 06:18:11 -0700 (PDT) Received: from EhalepXPS (ppp079166029189.access.hol.gr. [79.166.29.189]) by mx.google.com with ESMTPS id b3sm295524wie.0.2012.10.04.06.18.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 06:18:10 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> In-Reply-To: Date: Thu, 4 Oct 2012 16:18:06 +0300 Message-ID: <00a301cda232$b2216550$16642ff0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2hVNjJRKzjDDnySEa5OjTSmL9C1AA1SLyQ Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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, 04 Oct 2012 13:18:13 -0000 Greetings Jamal, Please see inline, Regards, Evangelos Haleplidis. > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Wednesday, October 03, 2012 1:50 PM > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] FW: New Version Notification for draft- > haleplidis-forces-model-extension-00.txt >=20 > Greetings Evangelos, >=20 > On Tue, Oct 2, 2012 at 5:43 PM, Haleplidis Evangelos = > wrote: > > Greetings Jamal, >=20 > > [=C5=C7] No, the only place I can set the default value is at the > > FlowTables component level. I can't set it at the FlowTableCounter > > definition. Like > > this: > > FlowTables > > Array{ > > struct of { > > FlowEntries (array) > > FlowTableCounter (struct) > > MissBehaviour (atomic) > > } > > } > > Default value of FlowTables =3D ... >=20 > That will look weird and i am not sure how youd write it out in the > xml. But i take it you can do this because components can have default > values and the FlowTables is a component. I guess i am struggling to > see the relevance of this specific use case. You could specify the the > counters to be zero at the datatype definition of Flow counter and > solve your problem. >=20 [=C5=C7] The problem is that I cannot define it at the datatype = definition. There is no default value in the original schema that allows datatypes = to have default values. The only place where default value is allowed is at the definition of a component of an LFB and only on the beginning of that definition. And = there is no formal way to say "only that component (counter) has that default value. >=20 > >> So i can see one use case where this would make sense. not sure if > >> this is what you are referencing above: > >> Example if i used struct FlowTableCounter in multiple places and > >> wanted different default values (example in ref1 i wanted all = fields > >> to have a default of 0 and in ref2 of FlowTableCounter wanted a > default of 1). > >> > > > > [=C5=C7] That's one use case. >=20 > And it can specify things at LFB component level now i realize i can > solve my problem here as well (so i dont need any schema extension). >=20 [=C5=C7] You can't solve it if all counters are a complex datatype = (which in this case it is). As above you can't define in a formal way which = counters will get which values. > > [=C5=C7] No. What I meant, is that when you define a dataTypeDef, = you can > > assign optional default value for the datatype. Therefore if you > > define a counter datatype, you can set a default value of zero, > > without having to set it multiple times if you use it multiple times > in an LFB definition. > > However, in order to avoid ambiguity, the text specifies that if a > > default value is added later in a component definition of an LFB, > then > > the default value in the component definition takes precedence. >=20 > Which makes sense. >=20 > > Additionally, this extension allows default values in metadata as > well. >=20 > We can already have default value in metadata I believe. >=20 [=C5=C7] You're right, the schema allows it but only in the definition = of the input port of an LFB if the metadata is optional. This extension allows you to define metadata at the metadata definition itself. However if nobody finds this useful, it can always be removed if nobody sees any value. The reason it was included was from the OF spec = which specified that the Action Set is empty by default. But that can also be defined in the input port as well. > I think the only ugly thing that seems to stick out at this point is > the way you would define things for something as deeply nested as the > FlowTables. >=20 [=C5=C7] You cannot define default values for nested components.=20 Even for a simple complex structure there is no formal way to say that. = For example: foobar foobar foo foo uint32 bar bar uint32 ??? There is no way to formally define with no ambiguity the default value = of the struct, or even one of the fields. > > [=C5=C7] Besides the need to change the text, we need also change = the > > schema to make it optional, since the schema enforces that as well. >=20 > Ok. Please prepare the errata. >=20 [=C5=C7] For the text: Page 65 Initial Text: lists the allowed frame formats... Proposed Text: MAY lists the allowed frame formats... Also, I think it should be valuable to say in the end: The element MUST contain at least either a frame format or a metadata. For the XML schema: Page 95 Initial text: New text: > > [=C5=C7] The current schema validation unfortunately occurs within = one > > single XML file. >=20 > Which is fine; just need to highlight that fact. >=20 [=C5=C7] Ok. > cheers, > jamal From hadi@mojatatu.com Fri Oct 5 04:34:35 2012 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 4B0E221F84C2 for ; Fri, 5 Oct 2012 04:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoqSI25iZ8pZ for ; Fri, 5 Oct 2012 04:34:34 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A30D721F8467 for ; Fri, 5 Oct 2012 04:34:34 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1965609oag.31 for ; Fri, 05 Oct 2012 04:34:34 -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:content-transfer-encoding:x-gm-message-state; bh=TIc+6GxGt42VHifN6Ns2mU8pyHEj1257GfpXV5Sbkl0=; b=mSN6FwobwE9NQwEzdELW4ymn7NCBlxwUVzlMOpR3T+D9dxbZnURWK09ObptKL1M7ou vNdvOiX8VYueXvJn+4C0aaZdpwlioLDUbqmUJ5I9RiW69e5gE/vrmYnFQ3n9aebt9eAK C8tVbOVO0szVrs2UGjwn1o4pR9XF1qf/dvh0N2RbWMrRF4Wqio1ca7IeslJUmhxUDxtF /NZidMOCG8b2yLcBEnGrICVtOqJvaa5eSOzz+iLVMvwkhehjwpqFItCtwaWihGEC/7wD faWriPtxhDAmcgSv2Y481fXZDW26x46WdLtPQrh+++DnxOi+kA/VYyfJviwo43WUNu9z v9GQ== Received: by 10.182.10.6 with SMTP id e6mr6816145obb.16.1349436874194; Fri, 05 Oct 2012 04:34:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.92.129 with HTTP; Fri, 5 Oct 2012 04:34:13 -0700 (PDT) In-Reply-To: <00a301cda232$b2216550$16642ff0$@com> References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> From: Jamal Hadi Salim Date: Fri, 5 Oct 2012 07:34:13 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnPBpZY4lObWbHM9ovdeqEuQoUv90WkYZFoPXjZr1Y6BEdWjH5bUAfcC932voNqX5SiGUkQ Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Fri, 05 Oct 2012 11:34:35 -0000 Greetings Evangelos, On Thu, Oct 4, 2012 at 9:18 AM, Haleplidis Evangelos wro= te: > [=C5=C7] The problem is that I cannot define it at the datatype definitio= n. > There is no default value in the original schema that allows datatypes to > have default values. Now that i think about it - you probably dont want datatype definition to allow for default values (since you cant have default values when the permission is read-only). So you are right, datatypes cant have default values. > The only place where default value is allowed is at the definition of a > component of an LFB and only on the beginning of that definition. And the= re > is no formal way to say "only that component (counter) has that default > value. Ok, sensible then; although i am still conflicted on the value of the propo= sal. Perhaps Joel will chime in. > > [=C5=C7] You're right, the schema allows it but only in the definition of= the > input port of an LFB if the metadata is optional. I recall during the early discussions - the point made was this was the onl= y time it made sense to have a default value for metadatum. i.e. If you receive metadata, it will always have a value. If it is optional and= you dont receive it, then you may need to produce one from a default value. > This extension allows you to define metadata at the metadata definition > itself. However if nobody finds this useful, it can always be removed if > nobody sees any value. The reason it was included was from the OF spec wh= ich > specified that the Action Set is empty by default. But that can also be > defined in the input port as well. Refer to my comment above. >> I think the only ugly thing that seems to stick out at this point is >> the way you would define things for something as deeply nested as the >> FlowTables. >> > > [=C5=C7] You cannot define default values for nested components. > Even for a simple complex structure there is no formal way to say that. F= or > example: > > foobar > foobar > > > foo > foo > uint32 > > > bar > bar > uint32 > > > ??? > Would the following not work?: foobar foobar foo foo uint32 1234 bar bar uint32 5678 I think it would be a problem if the typeref was a complex struct. > [=C5=C7] For the text: > Page 65 > Initial Text: The errata would need to be entered on the RFC IETF tools website. cheers, jamal From wwwrun@rfc-editor.org Sun Oct 7 14:41:50 2012 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 F10B921F86EA for ; Sun, 7 Oct 2012 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.578 X-Spam-Level: X-Spam-Status: No, score=-101.578 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQhpm9g10ZUQ for ; Sun, 7 Oct 2012 14:41:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7A21F86E5 for ; Sun, 7 Oct 2012 14:41:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BF6C7B1E002; Sun, 7 Oct 2012 14:37:07 -0700 (PDT) To: jmh@joelhalpern.com, hadi@mojatatu.com, stbryant@cisco.com, adrian@olddog.co.uk, dro@zurich.ibm.com, hadi@mojatatu.com From: RFC Errata System Message-Id: <20121007213707.BF6C7B1E002@rfc-editor.org> Date: Sun, 7 Oct 2012 14:37:07 -0700 (PDT) Cc: forces@ietf.org, ehalep@ece.upatras.gr, rfc-editor@rfc-editor.org Subject: [forces] [Editorial Errata Reported] RFC5812 (3371) 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, 07 Oct 2012 21:41:50 -0000 The following errata report has been submitted for RFC5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5812&eid=3371 -------------------------------------- Type: Editorial Reported by: Evangelos Haleplidis Section: GLOBAL Original Text ------------- Page 65 lists the allowed frame formats... For the XML schema: Page 95 Corrected Text -------------- Page 65 MAY lists the allowed frame formats... Also, I think it should be valuable to say in the end: The element MUST contain at least either a frame format or a metadata. For the XML schema: Page 95 Notes ----- Issue with frameProduced being mandatory for an output port. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5812 (draft-ietf-forces-model-16) -------------------------------------- Title : Forwarding and Control Element Separation (ForCES) Forwarding Element Model Publication Date : March 2010 Author(s) : J. Halpern, J. Hadi Salim Category : PROPOSED STANDARD Source : Forwarding and Control Element Separation Area : Routing Stream : IETF Verifying Party : IESG From ehalep@gmail.com Sun Oct 7 15:51:52 2012 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 9BA7421F861B for ; Sun, 7 Oct 2012 15:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTa2gdnts-xR for ; Sun, 7 Oct 2012 15:51:52 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 871A021F860E for ; Sun, 7 Oct 2012 15:51:51 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2427141wey.31 for ; Sun, 07 Oct 2012 15:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=qEiwNw777XYC5JF3sQLfy7YUk+FhJalC/wsAgv2SQXw=; b=dKhXMlDXVJMcx+NodMRev1L9WHR6KR4xKFvQHKxF68iFRwlpdjlKfLIee40tcOjeR6 Qcknmc6+qkti5DZVU0uBgJOpW/SGfkC1DQbK2P2pO+RBapzY0eWy0Amt1tFTdKQ0ilkD tPUQW8KJQXjgndjy1w4FVLvI1vuTIATlNQVq6lUvCFnuaTm79x5QhRkX62zldn3FjN4n sZ7V37ZeR6Ujtasbpf6N9+t/GGKfAhEtXyVkEnjGCynCMm9SdH72DN5b7VNmedWGih1i q2diuF2RiPXvyCiBTcupxTCZRxKMJ31Agx4a0mjFs/SqkBiSiQ71oNYld0xA5MaS6IQf cidg== Received: by 10.216.195.100 with SMTP id o78mr9382993wen.182.1349650310614; Sun, 07 Oct 2012 15:51:50 -0700 (PDT) Received: from EhalepXPS (ppp141237152070.access.hol.gr. [141.237.152.70]) by mx.google.com with ESMTPS id p4sm18365150wix.0.2012.10.07.15.51.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 15:51:50 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> In-Reply-To: Date: Mon, 8 Oct 2012 01:51:45 +0300 Message-ID: <007401cda4de$5503cda0$ff0b68e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2i7nTaA/6WZ9X5RPSQ7sW3UGlcCQB78sOw Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Sun, 07 Oct 2012 22:51:52 -0000 Greetings Jamal,=20 Please see inline. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On=20 > Behalf Of Jamal Hadi Salim > Sent: Friday, October 05, 2012 2:34 PM > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] FW: New Version Notification for draft-=20 > haleplidis-forces-model-extension-00.txt >=20 > Greetings Evangelos, >=20 > On Thu, Oct 4, 2012 at 9:18 AM, Haleplidis Evangelos=20 > > wrote: >=20 >=20 > > [=C5=C7] The problem is that I cannot define it at the datatype > definition. > > There is no default value in the original schema that allows > datatypes > > to have default values. >=20 > Now that i think about it - you probably dont want datatype definition = > to allow for default values (since you cant have default values when=20 > the permission is read-only). So you are right, datatypes cant have=20 > default values. >=20 [=C5=C7] Hm... why can't you have default values when the permission is read-only? Counters could be read-only. The value of the read-only component can be changed by the FE.=20 I don't think that having a default value is a problem in this case. > > The only place where default value is allowed is at the definition=20 > > of a component of an LFB and only on the beginning of that = definition. > > And there is no formal way to say "only that component (counter) has = > > that default value. >=20 > Ok, sensible then; although i am still conflicted on the value of the=20 > proposal. > Perhaps Joel will chime in. >=20 > > > > [=C5=C7] You're right, the schema allows it but only in the = definition=20 > > of the input port of an LFB if the metadata is optional. >=20 > I recall during the early discussions - the point made was this was=20 > the only time it made sense to have a default value for metadatum. = i.e. > If you receive metadata, it will always have a value. If it is=20 > optional and you dont receive it, then you may need to produce one=20 > from a default value. >=20 > > This extension allows you to define metadata at the metadata=20 > > definition itself. However if nobody finds this useful, it can=20 > > always be removed if nobody sees any value. The reason it was=20 > > included was from the OF spec which specified that the Action Set is = > > empty by default. But that can also be defined in the input port as well. >=20 > Refer to my comment above. >=20 [=C5=C7] Ok. I think that we can remove that. > >> I think the only ugly thing that seems to stick out at this point=20 > >> is the way you would define things for something as deeply nested=20 > >> as > the > >> FlowTables. > >> > > > > [=C5=C7] You cannot define default values for nested components. > > Even for a simple complex structure there is no formal way to say=20 > > that. For > > example: > > > > foobar > > foobar > > > > > > foo > > foo > > uint32 > > > > > > bar > > bar > > uint32 > > > > > > ??? > > >=20 >=20 > Would the following not work?: > > foobar > foobar > > > foo > foo > uint32 > 1234 > > > bar > bar > uint32 > 5678 > > > >=20 > I think it would be a problem if the typeref was a complex struct. >=20 [=C5=C7] This is what the new draft is trying to push. I agree it may be a problem, but that problem can be encountered on the current model as well.=20 At least in the new one, you could get a default value in a deeply = nested component. >=20 > > [=C5=C7] For the text: > > Page 65 > > Initial Text: >=20 > The errata would need to be entered on the RFC IETF tools website. >=20 [=C5=C7] Ok. Errata created.=20 > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Mon Oct 8 11:37:28 2012 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 F39EB21F8821 for ; Mon, 8 Oct 2012 11:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIMeQIxjl71y for ; Mon, 8 Oct 2012 11:37:26 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA0A321F881B for ; Mon, 8 Oct 2012 11:37:23 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so522428oag.31 for ; Mon, 08 Oct 2012 11:37:23 -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 :content-type:content-transfer-encoding:x-gm-message-state; bh=tlorX96MVKeWrzGsgj6Bf+At+63ReOjtlgBGfxYM0t8=; b=GO5S8THP2F6RISELuFifrlpJ5Gbw2slGyUj4MltV4vkvIKL95gi5kd1Fu9LZwHfAF3 DcZzd7jir3h7vYJa0yB2plnBN+VX+63ITMSE7DugEtTHVH64maQsrbRVXmf6vy+xDhuM Zi/4O+8RYlmnLPEfmEf/SDKHsC3l86Rqqil4Gd/GsCnWkW3AQ0HkJ/1aBVTSjhG9tFsa +uJQTQv8+PLnO/dXmeXvbIdcHbC12uX48PVyO1WF57PupwEfVoW6O0uPmJOZhwUdREkb loJLj0K4RRslir3pJ5Kjr9YcHRv4EkmkVr7q2Xagbphvp5NCU2hH6GrnN4+vb1wuCFs1 Ydjg== Received: by 10.60.172.112 with SMTP id bb16mr2513222oec.19.1349721442891; Mon, 08 Oct 2012 11:37:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.58.100 with HTTP; Mon, 8 Oct 2012 11:37:02 -0700 (PDT) In-Reply-To: References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> <006101cda4d4$c498e970$4dcabc50$@com> From: Jamal Hadi Salim Date: Mon, 8 Oct 2012 14:37:02 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmaoxrfEoyD5DNT6I2KWFAk/k/9lMyOp0Y0PSA/war3tt+VY3rlBM3oAulT7asj0CsiB8N2 Subject: [forces] Fwd: FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Mon, 08 Oct 2012 18:37:28 -0000 Sorry, meant to a respond-all... ---------- Forwarded message ---------- From: Jamal Hadi Salim Date: Mon, Oct 8, 2012 at 2:32 PM Subject: Re: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.txt To: Haleplidis Evangelos Greetings Evangelos, On Sun, Oct 7, 2012 at 5:43 PM, Haleplidis Evangelos wro= te: > [=C5=C7] Hm... why can't you have default values when the permission is > read-only? > > Counters could be read-only. The value of the read-only component can be > changed by the FE. > I don't think that having a default value is a problem in this case. I was going to say lets hear what Joel has to say - but my memory cells triggered: The FE can set whatever initial value it wishes - which may be the default value. That is separate from what the CE can write to it. The permissions reflect what the CE can do to the component. Having default values means in absence of the CE writing some value, there will be something default written to the component. >> I think it would be a problem if the typeref was a complex struct. > [=C5=C7] This is what the new draft is trying to push. > I agree it may be a problem, but that problem can be encountered on the > current model as well. > At least in the new one, you could get a default value in a deeply nested > component. Can you provide an example of how that would work? How would one describe a default for component foo.bar.goo.gah? What i showed would work for foo.bar without any changes. cheers, jamal From ehalep@gmail.com Tue Oct 9 10:52:27 2012 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 49A2A1F0CAB for ; Tue, 9 Oct 2012 10:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRImLNZcVQkn for ; Tue, 9 Oct 2012 10:52:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A34F1F0CB0 for ; Tue, 9 Oct 2012 10:52:12 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so3750576wey.31 for ; Tue, 09 Oct 2012 10:52:11 -0700 (PDT) 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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=V8iFvxmZ9mDvoKiliJfCTYFxxpan12fgCYA4UkWptj4=; b=GMHRBlt7+a+MG1mHMiOFLGjGOV4zodnKtn68znod6UEWVqF/wmdCl7Mq1uejOjj3W8 f3olMc4e4R+Bn+68kqTfOECRFmxqjDd34N6wQ76+P/ByX954phNFA/MNettG1ZfIeCM3 tW2stdK9LLGRmFsSSKYStGG587juyktG2erpswsjExqpdWJM0oS45P/zSbcEPWvu68NR 2Tf6S7kxdYOCqxCcrdoTqcV+0GEBk/kLaxD6us9iVykPW5ZJD/VwgmJziRYIJXBLTo6i N6Eq5E5u2t7kf5uSJYQLf9RkeTdlHvK//TYdKGkLcOYmctwMhoEeXlKzJp/w6x0TCm6b eTuQ== Received: by 10.216.207.28 with SMTP id m28mr2594235weo.52.1349805131445; Tue, 09 Oct 2012 10:52:11 -0700 (PDT) Received: from EhalepXPS (ppp046177119204.access.hol.gr. [46.177.119.204]) by mx.google.com with ESMTPS id dt9sm25933278wib.1.2012.10.09.10.52.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 10:52:10 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Tue, 9 Oct 2012 20:52:06 +0300 Message-ID: <019801cda646$cd503640$67f0a2c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2mR6hLdeTvJH7PRFuaibMrHHYs2AAARX1g Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-packet-parallelization-00.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: Tue, 09 Oct 2012 17:52:27 -0000 Greetings to the list, We have submitted a draft that tries to model parallelization using = ForCES. Comments and suggestions are more than welcome. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, October 09, 2012 8:50 PM > To: ehalep@ece.upatras.gr > Cc: joel.halpern@ericsson.com > Subject: New Version Notification for draft-haleplidis-forces-packet- > parallelization-00.txt >=20 >=20 > A new version of I-D, = draft-haleplidis-forces-packet-parallelization-00.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-packet-parallelization > Revision: 00 > Title: ForCES Model Extension > Creation date: 2012-10-09 > WG ID: Individual Submission > Number of pages: 26 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-packet-parall= elization-00.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-packet-paralleliz= ation > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-packet-parallelization= -00 >=20 >=20 > 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. >=20 > Many network devices support parallel packet processing. This > document describes how ForCES can model a network device's > parallelization datapath. >=20 >=20 >=20 >=20 > The IETF Secretariat From hadi@mojatatu.com Wed Oct 10 03:39:02 2012 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 2063521F856C for ; Wed, 10 Oct 2012 03:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhB9B4kNCbEj for ; Wed, 10 Oct 2012 03:39:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6106421F850B for ; Wed, 10 Oct 2012 03:39:01 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so411101obq.31 for ; Wed, 10 Oct 2012 03:39:00 -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=9qBDninDggYHO4vbDB5nVUDyBxL9e8/B+SaAI2UKM5k=; b=cAGH9hH0Zc7wpTEbgINALMrQNZ+0ndp8XT7QjQZyksNCAxEffiGJo8v2fbvD6hFfp/ UunmMOWyK/R47hZ2ozdNqzRUbtKVWX5K2W92Q0awbZzFFWa6PVKmPlqpN+L20ASvyVKa q8wmWWU3H/WwXnp800hoO00ErcShGHXimSGVRr5nvfPd+OPLp94rP4Qj6Phw8weO4KBQ 1sZb9XLxGRa0e6hMaCMfcZJCGAbW8sERjYbWmCQzIb2w3SardEdPoqVXVYo2bQxZg7Hr Dl4WjPKL6J93pWhn+QlFgV+bLUuZMXro2Ts+eCRbchs/ZxmTzzRgfu/8PQlxL+dFY2Zi UXvw== Received: by 10.182.46.65 with SMTP id t1mr5258167obm.20.1349865540366; Wed, 10 Oct 2012 03:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Wed, 10 Oct 2012 03:38:40 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 10 Oct 2012 06:38:40 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkNFyK2CvJx86oASIYDV4cHZiZMGufzR/4ubPR6by7LsmaAUPgFtGh/bM8YoH0OGMp2hFZd Cc: Joel Halpern , forces@ietf.org Subject: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.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, 10 Oct 2012 10:39:02 -0000 Comments: Generally, this is a useful extension 1)It is feasible to have a petri net kind of approach where multiple packets or chunks are sent to parallel LFBs and the merge proceeds after the first "success". Maybe make this a capability on the merge LFB. You specify whether the merge should wait for one or all LFB responses; you dont specify what the conditions for proceeding are. 2) You say the merger will merge multiple packets/chunks. If i am doing parallel TCAM lookups - I dont think i am looking to merge packets. I am looking to collect results (with the single copy of the packet). 3) Sentence which begins with "The FEObjectLFB must be able to specify for the LFB to be used in a parallel mode:" is confusing. It makes it appear like you are defining things - when in reality they already exist in the FEObject today. I think you need to say something like "The FEObject LFB currently specifies the LFBtopology to constitute of blah... In order to support the parallelization, the following additional componets are needed: ..." 4) ParallelType seems to have semantics for a config component as opposed to a metadatum. Why should i care if it is a packet or a fragment of? The "1 of N" semantics already tell me if i am receiving one or more packets. 5) ParallelID seems to be what would be commonly be called a (transactional) cookie. Why invent new nouns? 6) The granularity of the "valid" metadatum seems to need more than just being a boolean. Could you make it 32 bit and have it carry one of the pre-defined ForCES error codes? 7) I think you need to have use cases of real world use for both the flood vs split processing. Figure #2 is a good start but seems problematic with a meter LFB being run in parallel with a classifier; typically those are run in series. A parallel set of TCAMs or regex engines will be a good example of either modes (shows the same LFB class in parallel but different instances). cheers, jamal From ehalep@gmail.com Wed Oct 10 14:57:57 2012 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 7DAB111E808D for ; Wed, 10 Oct 2012 14:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urj0dutaJrsx for ; Wed, 10 Oct 2012 14:57:56 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4049111E808A for ; Wed, 10 Oct 2012 14:57:56 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so6254381wib.13 for ; Wed, 10 Oct 2012 14:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=XCAr6H+nbp0yYDOU7r+c4CRhCd76jtC5y3kvmsFr9Y4=; b=PdO4HbUGqTV8Mw8O8sQ82rzcH4q3YKkx6ClhnJ1CScjRG4L6uZFEw6clDNYUrXOp87 RZlcXvm2vWmTzl98ng3WeBA4aLVnTc03fDQJbplwRu4bL0yXjRCMZWtC2NMpuup4zQQQ 1cOV5fZSjgBiHPlMcuEksea2QVW4yQPOYnXZHlRVTatRRcdRqwQwwEdLnKfKc2J/oWlj 6DgajzcYcTfa1UI2D7omJzXTDfsSAgjZRGiqjd55cVxdSmLBg1xMBxkc4RE0qsQpOtlz +kNERUyCMibqf/kq6ABBK4sIUShs/WYJVwPMJmcZZMryaqOTuha/b9aW75N9hbDf04TM Rpig== Received: by 10.180.100.101 with SMTP id ex5mr15893114wib.16.1349906275351; Wed, 10 Oct 2012 14:57:55 -0700 (PDT) Received: from EhalepXPS (ppp079166054073.access.hol.gr. [79.166.54.73]) by mx.google.com with ESMTPS id k20sm32266846wiv.11.2012.10.10.14.57.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 14:57:54 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: In-Reply-To: Date: Thu, 11 Oct 2012 00:57:48 +0300 Message-ID: <01bc01cda732$4b0aba10$e1202e30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2m1LAEOB7GlLZ/QFWd2yYk1Gw8hwAFbOtQ Content-Language: el Cc: 'Joel Halpern' , forces@ietf.org Subject: Re: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.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, 10 Oct 2012 21:57:57 -0000 Greetings Jamal, Thanks for the comments. Please see inline. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Wednesday, October 10, 2012 1:39 PM > To: Haleplidis Evangelos > Cc: Joel Halpern; forces@ietf.org > Subject: [forces] Comments on draft-haleplidis-forces-packet- > parallelization-00.txt >=20 > Comments: > Generally, this is a useful extension >=20 > 1)It is feasible to have a petri net kind of approach where multiple > packets or chunks are sent to parallel LFBs and the merge proceeds > after the first "success". Maybe make this a capability on the merge > LFB. You specify whether the merge should wait for one or all LFB > responses; you dont specify what the conditions for proceeding are. >=20 [=C5=C7] Currently that is defined as a component in the Merger = (MergeWaitType). You can actually configure the Merger LFB on what you want it to do. = Wait for the first or wait for all. The first "success" would mean the first valid I guess, therefore you must set the InvalidAction to 1 (continue = merge on invalids). Does this cover your use case? > 2) You say the merger will merge multiple packets/chunks. > If i am doing parallel TCAM lookups - I dont think i am looking to > merge packets. I am looking to collect results (with the single copy = of > the packet). >=20 [=C5=C7] There two cases in this situation: 1. In the case of chunks you have a merge for sure. All the chunks have = to merged to the original packet. 2. In the case of packets, I think it's still a kind of a merge. Getting packets from all LFB instances in the parallel paths and you see that = they are all the same so you just keep one.=20 Unless I'm confusing terms. > 3) Sentence which begins with "The FEObjectLFB must be able to specify > for the LFB to be used in a parallel mode:" is confusing. It makes it > appear like you are defining things - when in reality they already > exist in the FEObject today. I think you need to say something like > "The FEObject LFB currently specifies the LFBtopology to constitute of > blah... In order to support the parallelization, the following > additional componets are needed: ..." >=20 [=C5=C7] Thanks, will change the text accordingly. What the text means = is that the LFBTopology will show the parallelization paths and the Supported = LFBs show supported LFBs and their relationship, but we need additional information to specify which LFBs can be parallel with which LFBs and = the order of LFBs in a parallel. > 4) ParallelType seems to have semantics for a config component as > opposed to a metadatum. Why should i care if it is a packet or a > fragment of? > The "1 of N" semantics already tell me if i am receiving one or more > packets. >=20 [=C5=C7] It depends on what you want to do. Parallel Type is used in = both the Splitter and the Merger. The Splitter gets it as a metadata to notify how the specific packet is supposed to be processed - split into chunks or send the same packet in = all instances. The reason we opted for having the ParallelType as metadata = is that it is more generic. Each packet can be treated differently based in = the ParallelType. It can be done as a configurable component but that would leave the type of parallelization same to all packets and up to the CE. = What would be the best option? In the case of the Merger, as all packets enter from the same group = input, it is required by the merger to distinguish chunks from packets to = correctly perform the merging. > 5) ParallelID seems to be what would be commonly be called a > (transactional) cookie. Why invent new nouns? >=20 [=C5=C7] ParallelID seemed semantically better than the word cookie.=20 > 6) The granularity of the "valid" metadatum seems to need more than > just being a boolean. Could you make it 32 bit and have it carry one = of > the pre-defined ForCES error codes? >=20 [=C5=C7] I guess you mean the RESULT-TLV result values. I don't think = that using the pre-defined error codes are a useful thing to do. Unless we define a subset of those errors, and even then I don't think we'll be able to = cover all cases.=20 My concern is, is the error code valuable for the Merger? What would the Merger do with such an information. Would it affect the merging process? = Do we need to define which error cases do not invalidate the merging = process and which do? =09 > 7) I think you need to have use cases of real world use for both the > flood vs split processing. Figure #2 is a good start but seems > problematic with a meter LFB being run in parallel with a classifier; > typically those are run in series. A parallel set of TCAMs or regex > engines will be a good example of either modes (shows the same LFB > class in parallel but different instances). >=20 [=C5=C7] Ok, thanks for the use cases. We will change the figures and = text appropriately. > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Thu Oct 11 04:38:05 2012 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 139B921F86F0 for ; Thu, 11 Oct 2012 04:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu8QLgkpbf80 for ; Thu, 11 Oct 2012 04:38:04 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5636F21F86DE for ; Thu, 11 Oct 2012 04:38:04 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1954991oag.31 for ; Thu, 11 Oct 2012 04:38:04 -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:content-transfer-encoding:x-gm-message-state; bh=/GlcP+n/IuqWEZUZ6gpi8DypNkUgvLd57r76k6g/hAs=; b=grUda5kRcMWJEvg4HnkBBbu7oaHdu5g6ORDa/KXe/wVUqW1PdkJthIL/02GbPZwqi1 1QngCw2pgHG4pL4ukA8+YZ8+f4vFk8YlTCPpB5eNcLMBm/iXeicYcQk1DYek8Smlzs9o pyQ8BqhYRFSUDeEkrc3RLzsnaaYdogGPiRdVS2OvAPFqTA3dHKLpFFdxzpomBrdHiO0/ W34gQbtBNxbe17jXmo3W6P3jPI+ZlBq1WWO8H67LIjdJaAygjNStwortSLZxChz6kV3a nUMDz6RRfXhnm3eA53zcDJMMC+aa3TI8Bu2R3eePy7XY1Zc7hdJ8InUkBd31w9B5TYQx gr1w== Received: by 10.182.23.79 with SMTP id k15mr385701obf.100.1349955483925; Thu, 11 Oct 2012 04:38:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Thu, 11 Oct 2012 04:37:43 -0700 (PDT) In-Reply-To: <01bc01cda732$4b0aba10$e1202e30$@com> References: <01bc01cda732$4b0aba10$e1202e30$@com> From: Jamal Hadi Salim Date: Thu, 11 Oct 2012 07:37:43 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7ttSWqLtcSmAzkLnx3eM6drDQUWFla7Yu8UuOGPDBpNLCyohNobt5m83YU6ZFsP4inDGD Cc: Joel Halpern , forces@ietf.org Subject: Re: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.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, 11 Oct 2012 11:38:05 -0000 Greetings Evangelos, On Wed, Oct 10, 2012 at 5:57 PM, Haleplidis Evangelos wr= ote: > [=C5=C7] Currently that is defined as a component in the Merger (MergeWai= tType). > You can actually configure the Merger LFB on what you want it to do. Wait > for the first or wait for all. The first "success" would mean the first > valid I guess, therefore you must set the InvalidAction to 1 (continue me= rge > on invalids). Does this cover your use case? > Maybe. I need to think about it a little more with some use case. I think if you returned an error code instead, it should certainly cover it= . > [=C5=C7] There two cases in this situation: > 1. In the case of chunks you have a merge for sure. All the chunks have t= o > merged to the original packet. > 2. In the case of packets, I think it's still a kind of a merge. Getting > packets from all LFB instances in the parallel paths and you see that the= y > are all the same so you just keep one. > Unless I'm confusing terms. I was thinking of this from an implementation perspective: The use cases playing in my head dont modify the packet - and the parralell LFB instances are running look-aside interfaces; so the copy of the packet stays with the sourcing LFB and the sourcing LFB also receives the response= s back (i.e it contains both the split and the merge functionality). > [=C5=C7] Thanks, will change the text accordingly. What the text means is= that > the LFBTopology will show the parallelization paths and the Supported LFB= s > show supported LFBs and their relationship, but we need additional > information to specify which LFBs can be parallel with which LFBs and the > order of LFBs in a parallel. You also need to describe that the parallelized LFBs need to understand the different metadata (valid in particular) and set them. > [=C5=C7] It depends on what you want to do. Parallel Type is used in both= the > Splitter and the Merger. > The Splitter gets it as a metadata to notify how the specific packet is > supposed to be processed - split into chunks or send the same packet in a= ll > instances. Gets it from what? I think a use case would be useful - I dont see one. >The reason we opted for having the ParallelType as metadata is > that it is more generic. >Each packet can be treated differently based in the > ParallelType. My view is the splitter would be very specific to one type or another. There is nothing intelligent along the path which will set this metadata. Only the splitter needs it. >It can be done as a configurable component but that would > leave the type of parallelization same to all packets and up to the CE. W= hat > would be the best option? Refer to the above. > In the case of the Merger, as all packets enter from the same group input= , > it is required by the merger to distinguish chunks from packets to correc= tly > perform the merging. You have the count with "This is 1 of N" semantics. If there was only one chunk N =3D=3D 1 > [=C5=C7] ParallelID seemed semantically better than the word cookie. It doesnt sound better to me ;-> But: your call. >> 6) The granularity of the "valid" metadatum seems to need more than >> just being a boolean. Could you make it 32 bit and have it carry one of >> the pre-defined ForCES error codes? >> > > [=C5=C7] I guess you mean the RESULT-TLV result values. yes. They are standardized already. > I don't think that using > the pre-defined error codes are a useful thing to do. Unless we define a > subset of those errors, and even then I don't think we'll be able to cove= r > all cases. It may not cover all cases - but will cover more than a boolean value. When failure occurs knowing what happens as precisely as possible is useful= . > My concern is, is the error code valuable for the Merger? What would the > Merger do with such an information. Would it affect the merging process? = Do > we need to define which error cases do not invalidate the merging process > and which do? Are you trying to save on bits? When the ForCES error codes were being standardized I was against using merely error codes - I wanted a string to describe what the error was to accompany the error code. My experience is when there are errors, you need as much details as you possibly can get. Allows for ease of debugg= ing. cheers, jamal From hadi@mojatatu.com Thu Oct 11 05:01:51 2012 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 2B85A21F86BE for ; Thu, 11 Oct 2012 05:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO-dA2rr9dK4 for ; Thu, 11 Oct 2012 05:01:50 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A99AE21F853E for ; Thu, 11 Oct 2012 05:01:50 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1981870oag.31 for ; Thu, 11 Oct 2012 05:01:50 -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=3NTY8oNK9twpaRpqH/Pcy0+NPxf+KandE92GXpK56HU=; b=HaHI3NiDXCGrVqlgYS+xEmG9HOTSXvik7tkBbozDAjKPrrwYI5mu8UgvoC7Hsu3lPl UGW/CHNfKEE54PbOfF03L89460BNlVVoLBZwn957JIU6u5RCq317kXdkF2v0c9ZihDJN Ly6dvhD8hMNpiDO6X4Emh8iIU2QTRVseCjYZC9Fd5q8U9mXu0DJDbti9HqcK1XNv9i2s BBmFROqgrF0UJOoIf1SSDchcfNgAbfP9OGF+V5o0SYYizlseg12HA9xDBhNJUkKpKPGp klHuib+6CZ3xIokgYSQXxO8zBzVl1xppVXu147mkJrSDgeRqX/e8zcS5+72q3775+APp pG8A== Received: by 10.60.170.9 with SMTP id ai9mr480866oec.36.1349956910126; Thu, 11 Oct 2012 05:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Thu, 11 Oct 2012 05:01:29 -0700 (PDT) In-Reply-To: <49044C2B7F64814BAA8D09EA7B8D72322DC53E7717@EUSAACMS0701.eamcs.ericsson.se> References: <01bc01cda732$4b0aba10$e1202e30$@com> <49044C2B7F64814BAA8D09EA7B8D72322DC53E7717@EUSAACMS0701.eamcs.ericsson.se> From: Jamal Hadi Salim Date: Thu, 11 Oct 2012 08:01:29 -0400 Message-ID: To: Joel Halpern Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmYljAtURQcoNqRwyXxoV3bp1lhAh/v8qUR7tsjCxp9Pvr6P+BWY2wZ/9oNdyvECT4l1XIZ Cc: "forces@ietf.org" Subject: Re: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.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, 11 Oct 2012 12:01:51 -0000 Hi Joel, On Wed, Oct 10, 2012 at 6:13 PM, Joel Halpern wrote: > There is an important reason for looking at it as a merge even when it was multiple copies of the same packet. > In many cases, we will get metadata from several branches. We need to pass on all the metadata. This does > not apply if the processing rule is just "pass the first, drop the others", but is otherwise necessary. Refer to the use case I provided in the earlier email (which is derived from implementation experience). I think your current underlying assumption is that the merging LFB instance will need to do "something" with the packet. In my use case the important detail is the metadata (and if the model says the merger received a packet that is fine too). > There are some pieces we need to add: > 1) When merging (slices or packets) if we get metadata from different packets with different values for >the same metadatum, what will ther merger do? There is one use case where different values of the metadata are a good thing. There may be need to have a "list of metadata" merged/accumulated (maybe that can be part of the earlier draft on complex metadata?). Ex: If i took a packet and split it to several regex match LFB instances, the merger may get metadata "matched foo at offset X" from all merged points. Something needs to aggregate that info so it could be used downstream. > 2) We need to note that "pass the first, drop the others" still requires that the merger keep state (but not content) >just as it would for a merge, since it needs to have the state for handling the later arrivals. indeed. cheers, jamal From joel.halpern@ericsson.com Wed Oct 10 15:13:29 2012 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 9CB1D21F86B4 for ; Wed, 10 Oct 2012 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85Q-QdvRNM9j for ; Wed, 10 Oct 2012 15:13:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7221F866B for ; Wed, 10 Oct 2012 15:13:29 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9AMELQo000655; Wed, 10 Oct 2012 17:14:23 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.44]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 10 Oct 2012 18:13:26 -0400 From: Joel Halpern To: Haleplidis Evangelos , "'Jamal Hadi Salim'" Date: Wed, 10 Oct 2012 18:13:24 -0400 Thread-Topic: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.txt Thread-Index: Ac2m1LAEOB7GlLZ/QFWd2yYk1Gw8hwAFbOtQABJgcuA= Message-ID: <49044C2B7F64814BAA8D09EA7B8D72322DC53E7717@EUSAACMS0701.eamcs.ericsson.se> References: <01bc01cda732$4b0aba10$e1202e30$@com> In-Reply-To: <01bc01cda732$4b0aba10$e1202e30$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Oct 2012 08:09:58 -0700 Cc: "forces@ietf.org" Subject: Re: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.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, 10 Oct 2012 22:13:29 -0000 In line for context...=20 > -----Original Message----- > From: Haleplidis Evangelos [mailto:ehalep@gmail.com]=20 > Sent: Wednesday, October 10, 2012 5:58 PM > To: 'Jamal Hadi Salim' > Cc: Joel Halpern; forces@ietf.org > Subject: RE: [forces] Comments on=20 > draft-haleplidis-forces-packet-parallelization-00.txt >=20 > Greetings Jamal, >=20 > Thanks for the comments. >=20 > Please see inline. >=20 > Regards, > Evangelos Haleplidis. >=20 > > -----Original Message----- > > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On=20 > > Behalf Of Jamal Hadi Salim > > Sent: Wednesday, October 10, 2012 1:39 PM > > To: Haleplidis Evangelos > > Cc: Joel Halpern; forces@ietf.org > > Subject: [forces] Comments on draft-haleplidis-forces-packet-=20 > > parallelization-00.txt > >=20 > > Comments: > > Generally, this is a useful extension ... > > 2) You say the merger will merge multiple packets/chunks. > > If i am doing parallel TCAM lookups - I dont think i am looking to=20 > > merge packets. I am looking to collect results (with the=20 > single copy=20 > > of the packet). > >=20 >=20 > [=C5=C7] There two cases in this situation: > 1. In the case of chunks you have a merge for sure. All the=20 > chunks have to merged to the original packet. > 2. In the case of packets, I think it's still a kind of a=20 > merge. Getting packets from all LFB instances in the parallel=20 > paths and you see that they are all the same so you just keep one.=20 > Unless I'm confusing terms. There is an important reason for looking at it as a merge even when it was = multiple copies of the same packet. In many cases, we will get metadata fr= om several branches. We need to pass on all the metadata. This does not a= pply if the processing rule is just "pass the first, drop the others", but = is otherwise necessary. There are some pieces we need to add: 1) When merging (slices or packets) if we get metadata from different packe= ts with different values for the same metadatum, what will ther merger do? 2) We need to note that "pass the first, drop the others" still requires th= at the merger keep state (but not content) just as it would for a merge, si= nce it needs to have the state for handling the later arrivals. ... Yours, Joel= From hadi@mojatatu.com Thu Oct 11 13:04:19 2012 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 0D6931F0C4A for ; Thu, 11 Oct 2012 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B-1W-QWKsj1 for ; Thu, 11 Oct 2012 13:04:18 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 772051F0C3E for ; Thu, 11 Oct 2012 13:04:18 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2635687oag.31 for ; Thu, 11 Oct 2012 13:04:18 -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 :content-type:x-gm-message-state; bh=wPVsO4DkwiTJVi9jkPui7vdhRVRkABp5odSPS4WE4DU=; b=AArgdTkpeip012CQxYA+pCn6nx9pzv9ddp7JnvHGd+hixH/P2261pM9PFDbW76jq8w u6NuJJrYnYg/NtMx4J4VUPEa9AE8UMEiE+WI+W3U86CUkCi7NnyjqqJ35Z7I5AfPr+bI bgqHhOdr3Fgt8EdlXTaaPw9J2ZciQeGXd1m8e0d+0Fwzcax92Q1J/0n5ocIfc5EFTAwt WT+m3L6w9a8xiTDLPoUXVVxi7nffNu1CdNfmrYkbrfgd565PMnOcMgVI+a6QtaKY/Usr LWIeqlRnbpcCWrtZUmX/hGu3CmA1CFLOFy2DAMtO1DbozZ5rJKYw4ZdXBkuoGBRFIp1L jpAA== Received: by 10.182.216.71 with SMTP id oo7mr1635569obc.70.1349985857907; Thu, 11 Oct 2012 13:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Thu, 11 Oct 2012 13:03:57 -0700 (PDT) In-Reply-To: <20121011182324.16701.45556.idtracker@ietfa.amsl.com> References: <20121011182324.16701.45556.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Thu, 11 Oct 2012 16:03:57 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnZL0TqPuOX9vNs71LgWZXG8Y0TCegZWa0dtgWrRdrlTslBO0iNkMktER9X92ZJFvT801Sz Subject: [forces] Fwd: I-D Action: draft-joachimpillai-forces-interfelfb-00.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, 11 Oct 2012 20:04:19 -0000 I didnt see this hit the list ... cheers, jamal ---------- Forwarded message ---------- From: Date: Thu, Oct 11, 2012 at 2:23 PM Subject: I-D Action: draft-joachimpillai-forces-interfelfb-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForCES Inter-FE LFB Author(s) : Damascane M. Joachimpillai Filename : draft-joachimpillai-forces-interfelfb-00.txt Pages : 16 Date : 2012-10-11 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. At the moment the ForCES charter restricts the LFB topology to be within an FE. This documents describes a non-intrusive way to extend the LFB topology across FEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-joachimpillai-forces-interfelfb There's also a htmlized version available at: http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hadi@mojatatu.com Sat Oct 13 08:39:55 2012 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 5357F21F8533 for ; Sat, 13 Oct 2012 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inRtB3GzpWIj for ; Sat, 13 Oct 2012 08:39:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BED8221F850B for ; Sat, 13 Oct 2012 08:39:54 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4530024obq.31 for ; Sat, 13 Oct 2012 08:39:54 -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 :content-type:x-gm-message-state; bh=nlYMbXUUbS2zMZrCFfa837kpTaX8TJE48MPBXuuGOKs=; b=X1Y9lBdY8k7/00djhLAErPV5GG4z5rlncC4FnB4A+VA2B2oQJP33VGrBsdOTlvEXON Us+8RcYNE42zij0C+czQaulrGqCnlMuYE4pZshCQvcUgNZ+XbQvPfLjO4TZGPqH0c/dK BynQmC63bxfTsNqS+cIzqu3bcPj43nLRrThTA2FrMhnTaIhtMoaE7k7SeYhuKodOUP1t MMW8Q8O176HZqYloqNhHyuU2hhJaaYB14GELH8a7zYgZd8RBS4TlhNBB2u5yrpbqAlht DbaESpKdkT2LVDNoFNQYUlbOWf1UL+b/mNUcaz03EGjhzzf1h7FPCduvUOm1zuQ8KvEr 4uKg== Received: by 10.60.26.72 with SMTP id j8mr43386oeg.68.1350142794314; Sat, 13 Oct 2012 08:39:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Sat, 13 Oct 2012 08:39:34 -0700 (PDT) In-Reply-To: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Sat, 13 Oct 2012 11:39:34 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkdV7Z+YVBg/Q8YAYALBeQrXxr+hkf45BGRHa1iQH9E6zy4d7BX4ZPNsUcP8DuYVKvGlpv5 Subject: [forces] Fwd: I-D Action: draft-djjhs-forces-lfbstate-00.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: Sat, 13 Oct 2012 15:39:55 -0000 New draft. Something buggy about the submission tool chops author information off. I reported it as a bug. cheers, jamal ---------- Forwarded message ---------- From: Date: Sat, Oct 13, 2012 at 11:19 AM Subject: I-D Action: draft-djjhs-forces-lfbstate-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForCES LFB Instance State Author(s) : Damascane M. Joachimpillai Mojatatu Networks Filename : draft-djjhs-forces-lfbstate-00.txt Pages : 7 Date : 2012-10-13 Abstract: The ForCES LFB Topology currently defines that once an instance of an LFB class is created it becomes immediately active in the datatapath. This document makes a slight extension to add state to an instantiated LFB class allowing the CE to decide when an LFB instance becomes operational on the datapath. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-djjhs-forces-lfbstate There's also a htmlized version available at: http://tools.ietf.org/html/draft-djjhs-forces-lfbstate-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jmh@joelhalpern.com Sat Oct 13 16:32:00 2012 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 688671F0381 for ; Sat, 13 Oct 2012 16:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tEztZPSjJbT for ; Sat, 13 Oct 2012 16:31:59 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D916421F844E for ; Sat, 13 Oct 2012 16:31:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 924C9A37E2 for ; Sat, 13 Oct 2012 16:31:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BEFF01C01A8 for ; Sat, 13 Oct 2012 16:31:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-76.clppva.btas.verizon.net [71.161.51.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 413F51C0072 for ; Sat, 13 Oct 2012 16:31:56 -0700 (PDT) Message-ID: <5079F9DC.9020807@joelhalpern.com> Date: Sat, 13 Oct 2012 19:31:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: forces References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> In-Reply-To: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Sat, 13 Oct 2012 23:32:00 -0000 Can the same ffect not already be achievd by the CE refrainign from connecting anything to the input ports of the LFB isntance ntil after it has filled in any of the parameters of interest? The normal sequence I would expect would be: Instantiate the LFB Set the elements to the desired values connect the output ports of the new LFB to the proper places in the topology connect the input ports in the lfb to the proper paces in the topology i necessary, change tables in other lfbs to make use of these new links. I am missing the reason for havig a new state for the LF a a whole. Yours, Joel On 10/13/2012 11:19 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : ForCES LFB Instance State > Author(s) : Damascane M. Joachimpillai > Mojatatu Networks > Filename : draft-djjhs-forces-lfbstate-00.txt > Pages : 7 > Date : 2012-10-13 > > Abstract: > The ForCES LFB Topology currently defines that once an instance of an > LFB class is created it becomes immediately active in the datatapath. > This document makes a slight extension to add state to an > instantiated LFB class allowing the CE to decide when an LFB instance > becomes operational on the datapath. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-djjhs-forces-lfbstate > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-djjhs-forces-lfbstate-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From hadi@mojatatu.com Sun Oct 14 04:03:18 2012 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 4E5D521F8495 for ; Sun, 14 Oct 2012 04:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O55pgqw7cCZC for ; Sun, 14 Oct 2012 04:03:17 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7A21F8491 for ; Sun, 14 Oct 2012 04:03:17 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so5054737oag.31 for ; Sun, 14 Oct 2012 04:03:16 -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=GA28N5eB8XvKRll1T08kgFasZ3eaBvYQSev9CeiQ3jA=; b=h/1OH2XjEDPnwHGIXjpMXplyppHt1INLdXgznxXaYOWFPw2AftHBPhwXv42m/MGP+c TeuDMSM2zzqLChXC+aFpW0ASAQsT139oJxPwqY/LHYf8LRhZUfI65VQ2wI6jOfkrogaN WNTh41n2wccTkf0PDaaYhK0PMZrEAOtnH0JK59vbuWT1BIZXmzky4Jq1uhO5/70LDgHI 3tJNwcYKV0p+4PKRjxNz75p6xdhEHp2x/JgVODHw/1zwTaOHCrD+E8BGizVn8WIUUoZ+ OmyUC2XH8QqWCFF+3Zmub5qSKjeM/KUvx+Wwso9AqT7AsNcvbu3B1SxXQVh9zCZuNAjV pgbw== Received: by 10.60.170.9 with SMTP id ai9mr7022015oec.36.1350212596584; Sun, 14 Oct 2012 04:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Sun, 14 Oct 2012 04:02:56 -0700 (PDT) In-Reply-To: <5079F9DC.9020807@joelhalpern.com> References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> From: Jamal Hadi Salim Date: Sun, 14 Oct 2012 07:02:56 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkwAoo9S4iiVFip2AuV/Z/H2LDkjgOKXWIZ32H6o5WzbLP+0AeBAhfX6pFNLm1+rkhPP1ro Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Sun, 14 Oct 2012 11:03:18 -0000 On Sat, Oct 13, 2012 at 7:31 PM, Joel M. Halpern wrote: > Can the same ffect not already be achievd by the CE refrainign from > connecting anything to the input ports of the LFB isntance ntil after it has > filled in any of the parameters of interest? That's one of the approaches we discussed. Two issues we faced: a) The LFBTopology is only sensible the FE's modifiabletopology is advertised as true. This may not always be the case. b) It provided the semantics of a graph link being inactive as opposed to the intended graph node (LFB instance) being inactive. For completion, one other approach we considered was to update the LFBTopology row with state - but that is also victim to LFBTopology and provides state semantics for a whole graph instead of a single node. cheers, jamal From hadi@mojatatu.com Sun Oct 14 04:05:20 2012 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 A927421F84F6 for ; Sun, 14 Oct 2012 04:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX7wp+Dxpe4d for ; Sun, 14 Oct 2012 04:05:20 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2CBF21F8491 for ; Sun, 14 Oct 2012 04:05:19 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so5055554oag.31 for ; Sun, 14 Oct 2012 04:05:19 -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=cxpIMJib7sAqppNW2ZDo8bHIP8J2d3yqJejHviuhd2U=; b=gDl7yUu3NdddxoipAsLFZyq0GPhaMxdqco4ecrSVdcnlsQ7KoqOxP3DrN76vJswLMA Nl40sAe8fF6ftY5tJcvealiij1A+7Yw6y/S4OBDCUkGnumQUOTsKzLpOavxI5G9FBtyj bm6hzudwm5Q+PJCf2fXPoMAmDYbP9CuBNnQofVWe1rmbTMytJLX6mVpemqZJrx5Bbi21 kXT5mQF2wecRAgZjss22hmEfCh+6MHoRGiFjpxMGvHU6oJdziBo4sY+I6gV5R2cQT+Ya 2nzFbezkFKJxQPUuv7cuSqgp/xLdR5vFnYxgtQDfDfd1gBcJH4a6AUo1iJcNyS9Hpo+r zciA== Received: by 10.182.131.100 with SMTP id ol4mr7228771obb.38.1350212719475; Sun, 14 Oct 2012 04:05:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Sun, 14 Oct 2012 04:04:59 -0700 (PDT) In-Reply-To: References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> From: Jamal Hadi Salim Date: Sun, 14 Oct 2012 07:04:59 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkokuXZPps343wllWG1INO1razgrfeorJT18vo9qALLBHDErB9pFmmCEX9d8FQEDLuNS0Tk Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Sun, 14 Oct 2012 11:05:20 -0000 Meant: On Sun, Oct 14, 2012 at 7:02 AM, Jamal Hadi Salim wrote: > but that is also victim to LFBTopology "victim to modifiabletopology..." cheers, jamal From jmh@joelhalpern.com Sun Oct 14 09:42:19 2012 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 5C4EF21F8458 for ; Sun, 14 Oct 2012 09:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNH644z9aPJC for ; Sun, 14 Oct 2012 09:42:19 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EF24B21F8450 for ; Sun, 14 Oct 2012 09:42:18 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 2E735A362A for ; Sun, 14 Oct 2012 09:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A09A61C0562; Sun, 14 Oct 2012 09:42:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-76.clppva.btas.verizon.net [71.161.51.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0B6261C0072; Sun, 14 Oct 2012 09:42:11 -0700 (PDT) Message-ID: <507AEB61.1050709@joelhalpern.com> Date: Sun, 14 Oct 2012 12:42:09 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Sun, 14 Oct 2012 16:42:19 -0000 The issue of a non-modifiabe topology requires some though. In my experiece, one usually can't turn individual LFBs on and off in such setup. Rather, with non-modifiable topologies the input ports tot eh FE sre rutnred off, the whole set of LFBs is configured, and then the input ports are turned on. My big problem with turning off an LFB is that it is completely unclear whatit means for the packet flow. What are we telling an upstream LFB to do when the downstream LFB is disabled? Drop the packet? Or is the CE supposed to assume that disabled LFBs are transparent? Both choices can produce extremely improper behavior. Put differently, it is not at all clear to we that a instantiated, connected, LFB can be meaningfully and safely disabled. Yours, Joel On 10/14/2012 7:02 AM, Jamal Hadi Salim wrote: > On Sat, Oct 13, 2012 at 7:31 PM, Joel M. Halpern wrote: >> Can the same ffect not already be achievd by the CE refrainign from >> connecting anything to the input ports of the LFB isntance ntil after it has >> filled in any of the parameters of interest? > > That's one of the approaches we discussed. Two issues we faced: > a) The LFBTopology is only sensible the FE's modifiabletopology is > advertised as true. This may not always be the case. > b) It provided the semantics of a graph link being inactive as opposed > to the intended graph node (LFB instance) being inactive. > > For completion, one other approach we considered was to update > the LFBTopology row with state - but that is also victim to > LFBTopology and provides state semantics for a whole graph > instead of a single node. > > cheers, > jamal > From adrian@olddog.co.uk Sun Oct 14 10:33:09 2012 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 3D94021F84D6 for ; Sun, 14 Oct 2012 10:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16XVCwF7EIZI for ; Sun, 14 Oct 2012 10:33:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42E21F84D3 for ; Sun, 14 Oct 2012 10:33:08 -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 q9EHX4St001082; Sun, 14 Oct 2012 18:33:04 +0100 Received: from 950129200 ([69.38.252.85]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9EHWwft001055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Oct 2012 18:33:03 +0100 From: "Adrian Farrel" To: Date: Sun, 14 Oct 2012 18:33:00 +0100 Message-ID: <00e401cdaa31$f8545c10$e8fd1430$@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: Ac2qF2RtuEufShZ2T+2qr+DdMF1lpA== Content-Language: en-gb Subject: [forces] The future of the ForCES WG 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: Sun, 14 Oct 2012 17:33:09 -0000 Hi WG, The chairs and I have been discussing the future of the WG for about a year. The working group work load has been pretty light, and between meetings the mailing list has been almost entirely dormant. In Paris we were all a bit surprised by the turn-out at the ForCES meeting and the sudden interest in comparing ForCES with OpenFlow. So we decided to let things run until Vancouver to see what happened. Between Paris and Vancouver there was pretty much silence, and so the chairs and I agreed that we would make sure everyone knew that they could post I-Ds and discuss "fringe" ForCES topics on the list. Jamal sent mail "opening those gates" on August 12. But the list was silent. So we got to discussing what would happen next. My preferred option is to declare success (we have the core ForCES RFCs) and close the WG. We would complete the existing WG I-Ds as AD sponsored, and keep the mailing list open for discussion of ForCES issues. But Jamal (good cop to my bad cop) persuaded me to let the WG run a bit more and to allow a meeting in Atlanta. And, true to form, you guys have managed to push out some new drafts just before the deadline. So this is what we'll do... Please think of the meeting in Atlanta as a sort of "ForCES continuation mini-BoF" What work could the working group move on to (including existing I-Ds)? And what is the commitment within the WG to push this work forward? I must explain that looking at the progress over the last 12 months, there doesn't seem to be enough energy to complete the current WG drafts, and that (lack of) progress colors how I look at the WG. So please do your best to prove Jamal right. Thanks, Adrian From hadi@mojatatu.com Mon Oct 15 03:47:36 2012 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 5B40821F86EA for ; Mon, 15 Oct 2012 03:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.018 X-Spam-Level: X-Spam-Status: No, score=-103.018 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UMO3SrKi1x0 for ; Mon, 15 Oct 2012 03:47:35 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C973421F86E5 for ; Mon, 15 Oct 2012 03:47:35 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so5852881oag.31 for ; Mon, 15 Oct 2012 03:47:35 -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=QjaG/s1C2UM7XaPXZTcvx7XwMJfEUo2zuKNbdi4QlwI=; b=ayitWYasOxjbsJ76udxsdGsG1OcI/rEOyeIbB4rWWhbWMFg7JUdcRrPJvIyxGlrto/ eZemW8A33stdCbSukCd8j1ZQ+fy2ifQhevzjnunX7ef+H4LNwSuLWBP6Uio7HDyg+U3k GNnY6NJ5XtCFoFt+3Ho+IuW4RiB9gzxoHddGVY7DnCaTOS/Qzp8w+AbBYgzHSRA+oz8N pNSVh6XAZ4oLkyW3RLWWtry+3K4vKgyndUleE8hQDma9oMaUydDPufyfx8kMntSrQJNa tuWtIlW+gnqDMZY/EQUpCyEF1J32CI1ZbNugfSz1QC4w9HdIjqJnBxJq8rgVNgLI1CHM vUOw== Received: by 10.182.23.79 with SMTP id k15mr9230317obf.100.1350298055299; Mon, 15 Oct 2012 03:47:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Mon, 15 Oct 2012 03:47:14 -0700 (PDT) In-Reply-To: <507AEB61.1050709@joelhalpern.com> References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> <507AEB61.1050709@joelhalpern.com> From: Jamal Hadi Salim Date: Mon, 15 Oct 2012 06:47:14 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmReDTCITe9RhX+EZ97h1HqFgN5omi9AZ9ADB4iD74IZ/i1ow1L2df4OXcyelQvpUu3FnV+ Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Mon, 15 Oct 2012 10:47:36 -0000 On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern wrote: > The issue of a non-modifiabe topology requires some though. In > my experiece, one usually can't turn individual LFBs on and off >in such setup. Rather, with non-modifiable topologies the input > ports tot eh FE sre rutnred off, the whole set of LFBs is >configured, and then the input ports are turned on. What you just described with "the input ports turned off" is essentially meant to be signalled by the FEO::FEState being put in AdminDisable. And i think in this case that would be an implementation approach (which is of course reasonable). There are ASICs where you dont have to turn off ports. You need to bang some registers to turn/off the datapath. And in that case I would rather set some bits in registers instead iterating the port list and turn off ports. If you assumed we can ignore non-modifiabe topology semantics, it still looks different and complex (youd have to scan the LFB topology and turn off every link to that LFB instance). It will solve one of our stated goals (the race condition aspect) but would be cumbersome for the HA aspect. > My big problem with turning off an LFB is that it is completely > unclear what it means for the packet flow. The semantics are the same as FEO::FEState If the FEState is Admin/OperDisable it provides the illusion that all LFB instances are inactive on the datapath. >What are we telling an upstream LFB to do > when the downstream LFB is disabled? Drop the packet? > Or is the CE > supposed to assume that disabled LFBs are transparent? Both choices can > produce extremely improper behavior. Agreed - the FE advertising this capability must be able to handle the configuration. Implementation specific perhaps, but one way is to empty any control components related to the LFB instance from the datapath. In our case the FE would store the inactive Instance information in software (but not in the datapath) and activation implies storing it into the datapath. > Put differently, it is not at all clear to we that a instantiated, > connected, LFB can be meaningfully and safely disabled. It may end up being implementation specific as is the case of FEO::FEState. cheers, jamal From jmh@joelhalpern.com Mon Oct 15 07:29:03 2012 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 69AB721F86DE for ; Mon, 15 Oct 2012 07:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEhLyv-K7vJJ for ; Mon, 15 Oct 2012 07:29:02 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AA4EC21F86CE for ; Mon, 15 Oct 2012 07:29:02 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id A10A8A3992 for ; Mon, 15 Oct 2012 07:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1379B1C07E8; Mon, 15 Oct 2012 07:29:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-76.clppva.btas.verizon.net [71.161.51.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 15F071C0426; Mon, 15 Oct 2012 07:28:59 -0700 (PDT) Message-ID: <507C1DA8.2040509@joelhalpern.com> Date: Mon, 15 Oct 2012 10:28:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> <507AEB61.1050709@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Mon, 15 Oct 2012 14:29:03 -0000 I have to strongly disagree. With regard to turning off physical ports, there are two reasons that apply to physical ports, and do not apply to the logical input ports of LFBs. 1) This is a semantic that human beings express. 2) More importantly, the upstream of these physical ports is in general not under the control of the CE. So the CE & FEs have to be prepared for it doing unexpected things. With regard to CE operation, there is no need for admin-disabling port. In fact, doing so will add needless steps to the operation of setting up a new or changed configuration. When making any configuration change to LFBs, the CE has to a) determine what changes it wants to make. For modifiable topologies, this may mean planning to create some LFB instances and / or planing to create some links. For any FE, this will meaning determining what LFB parameters changes it wants to make. b) The CE then evaluates the dependencies between this changes. It arranges them into a dependency graph. And then applies the changes from the root of the graph towards the leaves. If the CE does not do this, then there will be times when the FE will behave in unpredictable and probably undesirable ways. If the CE does do this, there is never a need to turn off an LFB port. With regard to (b), if that sort can ot be done, the adding admin-disable to individual LFB logical input ports will not help make it possible. As a minor note, there are cases where, n order to preserve te dependency properly, one may have to make certain temporary config changes. As a CE coder, one can choose between the more complex math to find the stable behavior or having the transient improper behavior. Again, the admin-disable will not help. I will admit that in the above I am assuming that it is irrelevant to try to determine the "meaning" of a topology and configuration in the middle of a change. With or without admin-disable on logical LFB input ports, such interpretation of what was actually intended as a transient state is probably very hard. Yours, Joel PS: I am happy to discuss this in the meeting in Atlanta if we need to. On 10/15/2012 6:47 AM, Jamal Hadi Salim wrote: > On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern wrote: >> The issue of a non-modifiabe topology requires some though. In > my experiece, one usually can't turn individual LFBs on and off >in such setup. Rather, with non-modifiable topologies the input >> ports tot eh FE sre rutnred off, the whole set of LFBs is >configured, and then the input ports are turned on. > > What you just described with "the input ports turned off" > is essentially meant to be signalled by the FEO::FEState being put in > AdminDisable. And i think in this case that would be an > implementation approach (which is of course reasonable). > There are ASICs where you dont have to turn off ports. > You need to bang some registers to turn/off the datapath. > And in that case I would rather set some bits in registers > instead iterating the port list and turn off ports. > > If you assumed we can ignore non-modifiabe topology semantics, > it still looks different and complex (youd have to scan the LFB > topology and turn off every link to that LFB instance). > It will solve one of our stated goals (the race condition aspect) > but would be cumbersome for the HA aspect. > >> My big problem with turning off an LFB is that it is completely >> unclear what it means for the packet flow. > > The semantics are the same as FEO::FEState > If the FEState is Admin/OperDisable it provides the illusion that > all LFB instances are inactive on the datapath. > >> What are we telling an upstream LFB to do >> when the downstream LFB is disabled? Drop the packet? >> Or is the CE >> supposed to assume that disabled LFBs are transparent? Both choices can >> produce extremely improper behavior. > > Agreed - the FE advertising this capability must be able to handle > the configuration. > Implementation specific perhaps, but one way is to empty any > control components related to the LFB instance from the datapath. > In our case the FE would store the inactive Instance information in software > (but not in the datapath) and activation implies storing it into the datapath. > >> Put differently, it is not at all clear to we that a instantiated, >> connected, LFB can be meaningfully and safely disabled. > > It may end up being implementation specific as is the > case of FEO::FEState. > > cheers, > jamal > From hadi@mojatatu.com Tue Oct 16 04:57:43 2012 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 569F821F8948 for ; Tue, 16 Oct 2012 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.016 X-Spam-Level: X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QwRWPkuWhAA for ; Tue, 16 Oct 2012 04:57:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBF821F8943 for ; Tue, 16 Oct 2012 04:57:42 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so7292309obq.31 for ; Tue, 16 Oct 2012 04:57:42 -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=fEbcH7UTisqeJ4t1+KA3pFI5d3eoBYtXKGTqDnhxhjg=; b=E1uTno9MTeumUZwuptu279BdKM+AYgmD4bVdbP0qtGU6DOoLIjDeeoahGv3Vt7IDgc gWfNh5bV5BqyDay37ebuXKodl5YPDHCd9CIjGBDMu1MS4/SRlLqHIP3u3gkIVEs2NLHm rGWyRBe6kelsNF3nwJJ48JO3rHMhSnLPZ3Gn8F87YyAep4vWmESv9iPuXaMJSvYD8I5/ /ez31s3eyMW3oh9f11krMI3pl/KjAstLJ/w1RG7v3TgNdEUWXDcp8RhRhJNxfE+FcfyA x0qL7L1KtyQWE/s0GfUyyQ/DWp1v5TjdLAomRZDe3A2TtAQ81+aQ0gsNLplMIBewtyMv Ry0A== Received: by 10.182.131.100 with SMTP id ol4mr12134753obb.38.1350388662113; Tue, 16 Oct 2012 04:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Tue, 16 Oct 2012 04:57:21 -0700 (PDT) In-Reply-To: <507C1DA8.2040509@joelhalpern.com> References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> <507AEB61.1050709@joelhalpern.com> <507C1DA8.2040509@joelhalpern.com> From: Jamal Hadi Salim Date: Tue, 16 Oct 2012 07:57:21 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnuelltB/mjE/SDDq4RxSTkSBy7KbKXghqI+2pYQXaBtCQfwKhJIT6uCSR01upmzs8QcsEs Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Tue, 16 Oct 2012 11:57:43 -0000 Joel, We may have digressed given i hardly disagree with what you said in your email below (and it may be orthogonal to our goals). Here's what we mainly want to achieve: Send config info to a specific LFB Instance. Decide when that info becomes active or inactive in the datapath. We want to do this in presence of many active graphs within an active FE (which receives traffic). Willing to have the LFB instance of interest to belong to only one service graph, but more importantly we want to achieve this in as fewer steps as possible (on the message exchange level). The disagreement i have is i think you are describing an implementation approach. Maybe this is left up to a face to face discussion at the meeting. Again, our goal is to take the FEState semantic and express it at the LFB instance level. With FEState there is an equivalent semantic at the coarse granularity of the FE i.e CE can update the config and when ready send a single message which says "activate" . How the isolation of the FE is achieved is up to the implementer. You describe isolation of the FE as being achieved by turning off physical ports on the datapath. I described an ASIC that could be sent a single message at the register level to achieve that same goal. As it stands right now, the interpretation of activate/deactivate is left up to the implementation. Thats where we draw our motivation. cheers, jamal On Mon, Oct 15, 2012 at 10:28 AM, Joel M. Halpern wrote: > I have to strongly disagree. > > With regard to turning off physical ports, there are two reasons that apply > to physical ports, and do not apply to the logical input ports of LFBs. > 1) This is a semantic that human beings express. > 2) More importantly, the upstream of these physical ports is in general not > under the control of the CE. So the CE & FEs have to be prepared for it > doing unexpected things. > > With regard to CE operation, there is no need for admin-disabling port. In > fact, doing so will add needless steps to the operation of setting up a new > or changed configuration. When making any configuration change to LFBs, the > CE has to > a) determine what changes it wants to make. For modifiable topologies, this > may mean planning to create some LFB instances and / or planing to create > some links. For any FE, this will meaning determining what LFB parameters > changes it wants to make. > b) The CE then evaluates the dependencies between this changes. It arranges > them into a dependency graph. And then applies the changes from the root of > the graph towards the leaves. If the CE does not do this, then there will > be times when the FE will behave in unpredictable and probably undesirable > ways. If the CE does do this, there is never a need to turn off an LFB > port. > > With regard to (b), if that sort can ot be done, the adding admin-disable to > individual LFB logical input ports will not help make it possible. > > As a minor note, there are cases where, n order to preserve te dependency > properly, one may have to make certain temporary config changes. As a CE > coder, one can choose between the more complex math to find the stable > behavior or having the transient improper behavior. Again, the admin-disable > will not help. > > I will admit that in the above I am assuming that it is irrelevant to try to > determine the "meaning" of a topology and configuration in the middle of a > change. With or without admin-disable on logical LFB input ports, such > interpretation of what was actually intended as a transient state is > probably very hard. > > Yours, > Joel > > PS: I am happy to discuss this in the meeting in Atlanta if we need to. > > > On 10/15/2012 6:47 AM, Jamal Hadi Salim wrote: >> >> On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern >> wrote: >>> >>> The issue of a non-modifiabe topology requires some though. In > my >>> experiece, one usually can't turn individual LFBs on and off >in such setup. >>> Rather, with non-modifiable topologies the input >>> ports tot eh FE sre rutnred off, the whole set of LFBs is >configured, >>> and then the input ports are turned on. >> >> >> What you just described with "the input ports turned off" >> is essentially meant to be signalled by the FEO::FEState being put in >> AdminDisable. And i think in this case that would be an >> implementation approach (which is of course reasonable). >> There are ASICs where you dont have to turn off ports. >> You need to bang some registers to turn/off the datapath. >> And in that case I would rather set some bits in registers >> instead iterating the port list and turn off ports. >> >> If you assumed we can ignore non-modifiabe topology semantics, >> it still looks different and complex (youd have to scan the LFB >> topology and turn off every link to that LFB instance). >> It will solve one of our stated goals (the race condition aspect) >> but would be cumbersome for the HA aspect. >> >>> My big problem with turning off an LFB is that it is completely >>> unclear what it means for the packet flow. >> >> >> The semantics are the same as FEO::FEState >> If the FEState is Admin/OperDisable it provides the illusion that >> all LFB instances are inactive on the datapath. >> >>> What are we telling an upstream LFB to do >>> when the downstream LFB is disabled? Drop the packet? >>> Or is the CE >>> supposed to assume that disabled LFBs are transparent? Both choices can >>> produce extremely improper behavior. >> >> >> Agreed - the FE advertising this capability must be able to handle >> the configuration. >> Implementation specific perhaps, but one way is to empty any >> control components related to the LFB instance from the datapath. >> In our case the FE would store the inactive Instance information in >> software >> (but not in the datapath) and activation implies storing it into the >> datapath. >> >>> Put differently, it is not at all clear to we that a instantiated, >>> connected, LFB can be meaningfully and safely disabled. >> >> >> It may end up being implementation specific as is the >> case of FEO::FEState. >> >> cheers, >> jamal >> > From jmh@joelhalpern.com Tue Oct 16 06:49:48 2012 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 D188721F8770 for ; Tue, 16 Oct 2012 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jnqk32Xb07s for ; Tue, 16 Oct 2012 06:49:47 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DB00F21F875C for ; Tue, 16 Oct 2012 06:49:47 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E14F8A6670 for ; Tue, 16 Oct 2012 06:49:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 235811C082A; Tue, 16 Oct 2012 06:49:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-221.clppva.btas.verizon.net [71.161.51.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EA01B1C0846; Tue, 16 Oct 2012 06:49:42 -0700 (PDT) Message-ID: <507D65F4.7030604@joelhalpern.com> Date: Tue, 16 Oct 2012 09:49:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> <507AEB61.1050709@joelhalpern.com> <507C1DA8.2040509@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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: Tue, 16 Oct 2012 13:49:48 -0000 I am sorry, I still don't see the problem. Suppose we have an FE with a non-modifiable topology. Suppose that there is some LFB in the topology that we want to configure, but do not want to use. Fine, do so. By definition, if we are not using that LFB, we are not directing any packets to it. If the upstream never sends an packets to it, then whether the LFB is administratively enabled or administratively disabled is irrelevant. Remember, the CE knows what it wants, and what it is doing. The admin state of the LFB won't tell it anything it doesn't know. In essence, this is a mathematical statement. If we want a predictable behavior, then the graph has to avid sending any packets to any non-used LFBs. enabled or disabled is irrelevant. Yours, Joel On 10/16/2012 7:57 AM, Jamal Hadi Salim wrote: > Joel, > > We may have digressed given i hardly disagree with what you said in > your email below (and it may be orthogonal to our > goals). Here's what we mainly want to achieve: > Send config info to a specific LFB Instance. Decide when that info > becomes active or inactive in the datapath. We want to do > this in presence of many active graphs within an active FE > (which receives traffic). Willing to have the LFB instance of > interest to belong to only one service graph, but more importantly we > want to achieve this in as fewer steps as possible (on the message > exchange level). > > The disagreement i have is i think you are describing an > implementation approach. Maybe this is left up to a face to face > discussion at the meeting. > Again, our goal is to take the FEState semantic and express > it at the LFB instance level. > With FEState there is an equivalent semantic at the coarse granularity > of the FE i.e CE can update the config and when ready send a single > message which says "activate" . How the isolation of the FE is > achieved is up to the implementer. You describe isolation of the FE as > being achieved by turning off physical ports on the datapath. I > described an ASIC that could be sent a single message at the register > level to achieve that same goal. > As it stands right now, the interpretation of activate/deactivate > is left up to the implementation. Thats where we draw our > motivation. > > cheers, > jamal > > > > On Mon, Oct 15, 2012 at 10:28 AM, Joel M. Halpern wrote: >> I have to strongly disagree. >> >> With regard to turning off physical ports, there are two reasons that apply >> to physical ports, and do not apply to the logical input ports of LFBs. >> 1) This is a semantic that human beings express. >> 2) More importantly, the upstream of these physical ports is in general not >> under the control of the CE. So the CE & FEs have to be prepared for it >> doing unexpected things. >> >> With regard to CE operation, there is no need for admin-disabling port. In >> fact, doing so will add needless steps to the operation of setting up a new >> or changed configuration. When making any configuration change to LFBs, the >> CE has to >> a) determine what changes it wants to make. For modifiable topologies, this >> may mean planning to create some LFB instances and / or planing to create >> some links. For any FE, this will meaning determining what LFB parameters >> changes it wants to make. >> b) The CE then evaluates the dependencies between this changes. It arranges >> them into a dependency graph. And then applies the changes from the root of >> the graph towards the leaves. If the CE does not do this, then there will >> be times when the FE will behave in unpredictable and probably undesirable >> ways. If the CE does do this, there is never a need to turn off an LFB >> port. >> >> With regard to (b), if that sort can ot be done, the adding admin-disable to >> individual LFB logical input ports will not help make it possible. >> >> As a minor note, there are cases where, n order to preserve te dependency >> properly, one may have to make certain temporary config changes. As a CE >> coder, one can choose between the more complex math to find the stable >> behavior or having the transient improper behavior. Again, the admin-disable >> will not help. >> >> I will admit that in the above I am assuming that it is irrelevant to try to >> determine the "meaning" of a topology and configuration in the middle of a >> change. With or without admin-disable on logical LFB input ports, such >> interpretation of what was actually intended as a transient state is >> probably very hard. >> >> Yours, >> Joel >> >> PS: I am happy to discuss this in the meeting in Atlanta if we need to. >> >> >> On 10/15/2012 6:47 AM, Jamal Hadi Salim wrote: >>> >>> On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern >>> wrote: >>>> >>>> The issue of a non-modifiabe topology requires some though. In > my >>>> experiece, one usually can't turn individual LFBs on and off >in such setup. >>>> Rather, with non-modifiable topologies the input >>>> ports tot eh FE sre rutnred off, the whole set of LFBs is >configured, >>>> and then the input ports are turned on. >>> >>> >>> What you just described with "the input ports turned off" >>> is essentially meant to be signalled by the FEO::FEState being put in >>> AdminDisable. And i think in this case that would be an >>> implementation approach (which is of course reasonable). >>> There are ASICs where you dont have to turn off ports. >>> You need to bang some registers to turn/off the datapath. >>> And in that case I would rather set some bits in registers >>> instead iterating the port list and turn off ports. >>> >>> If you assumed we can ignore non-modifiabe topology semantics, >>> it still looks different and complex (youd have to scan the LFB >>> topology and turn off every link to that LFB instance). >>> It will solve one of our stated goals (the race condition aspect) >>> but would be cumbersome for the HA aspect. >>> >>>> My big problem with turning off an LFB is that it is completely >>>> unclear what it means for the packet flow. >>> >>> >>> The semantics are the same as FEO::FEState >>> If the FEState is Admin/OperDisable it provides the illusion that >>> all LFB instances are inactive on the datapath. >>> >>>> What are we telling an upstream LFB to do >>>> when the downstream LFB is disabled? Drop the packet? >>>> Or is the CE >>>> supposed to assume that disabled LFBs are transparent? Both choices can >>>> produce extremely improper behavior. >>> >>> >>> Agreed - the FE advertising this capability must be able to handle >>> the configuration. >>> Implementation specific perhaps, but one way is to empty any >>> control components related to the LFB instance from the datapath. >>> In our case the FE would store the inactive Instance information in >>> software >>> (but not in the datapath) and activation implies storing it into the >>> datapath. >>> >>>> Put differently, it is not at all clear to we that a instantiated, >>>> connected, LFB can be meaningfully and safely disabled. >>> >>> >>> It may end up being implementation specific as is the >>> case of FEO::FEState. >>> >>> cheers, >>> jamal >>> >> > From hadi@mojatatu.com Wed Oct 17 04:00:05 2012 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 A7C5B21F8754 for ; Wed, 17 Oct 2012 04:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.014 X-Spam-Level: X-Spam-Status: No, score=-103.014 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBRguQEaRPCM for ; Wed, 17 Oct 2012 04:00:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9D21F874C for ; Wed, 17 Oct 2012 04:00:04 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so8681202obq.31 for ; Wed, 17 Oct 2012 04:00:04 -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=5XVJVwqbsvz+z+09pTNzAfNQfhGksnSIjfVgkEqU1sM=; b=IaMWdwpiMjJJhKDdD7XPPKOGQEGEuhiN5iJh8iGyC7Jw/q3dMDdfzRDYgAO3NxVelr 59Khy1k4tbEpqLvpu7WFL6mzhxBYrAXOduWTtY0on2RbHQeBHvPqxUnrER6kIC4ULYHq Zu4W4VeJyNtHLpYtZFx9YV7SHDetJyMFAKFxf1lYSz+LM5fEgpjWunCdr3MuvONV0bx7 0alJfqZ8X5E6NoB4+XWBu9SZfZYfFQJCTo03EZMAFlTivCPYiLvTXCVrNVfg6Hw6XPn2 Sx+gmsT2nHqnhx1n4ixKleTCRGHvu19prUlU3SehErgoAbbYjvZAcOmuXucjDL9CHB1T Unnw== Received: by 10.182.216.71 with SMTP id oo7mr14685115obc.70.1350471604151; Wed, 17 Oct 2012 04:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Wed, 17 Oct 2012 03:59:43 -0700 (PDT) In-Reply-To: <507D65F4.7030604@joelhalpern.com> References: <20121013151956.19317.96789.idtracker@ietfa.amsl.com> <5079F9DC.9020807@joelhalpern.com> <507AEB61.1050709@joelhalpern.com> <507C1DA8.2040509@joelhalpern.com> <507D65F4.7030604@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 17 Oct 2012 06:59:43 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkRzo58b03zZExukpiJx+gDGE/pdI9YN0vOvfbOuYPNmP5MHaRpxuZa3Z15Q7Feps+x80jA Cc: forces Subject: Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.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, 17 Oct 2012 11:00:05 -0000 Joel, Lets defer this discussion to th meeting time; you may be able to convince us or us convince you. Ignoring the non-modifiable topology issue... It becomes a usability issue if an LFB instanc belongs to more than one topology (more messages). The maybe purist arguement is : if a node in a graph is tagged "down" that implies in every topology where this node participates there is no connectivity to it. cheers, jamal On Tue, Oct 16, 2012 at 9:49 AM, Joel M. Halpern wrote: > I am sorry, I still don't see the problem. > > Suppose we have an FE with a non-modifiable topology. Suppose that there is > some LFB in the topology that we want to configure, but do not want to use. > > Fine, do so. > > By definition, if we are not using that LFB, we are not directing any > packets to it. If the upstream never sends an packets to it, then whether > the LFB is administratively enabled or administratively disabled is > irrelevant. Remember, the CE knows what it wants, and what it is doing. > The admin state of the LFB won't tell it anything it doesn't know. > > In essence, this is a mathematical statement. If we want a predictable > behavior, then the graph has to avid sending any packets to any non-used > LFBs. enabled or disabled is irrelevant. > > Yours, > Joel > > > On 10/16/2012 7:57 AM, Jamal Hadi Salim wrote: >> >> Joel, >> >> We may have digressed given i hardly disagree with what you said in >> your email below (and it may be orthogonal to our >> goals). Here's what we mainly want to achieve: >> Send config info to a specific LFB Instance. Decide when that info >> becomes active or inactive in the datapath. We want to do >> this in presence of many active graphs within an active FE >> (which receives traffic). Willing to have the LFB instance of >> interest to belong to only one service graph, but more importantly we >> want to achieve this in as fewer steps as possible (on the message >> exchange level). >> >> The disagreement i have is i think you are describing an >> implementation approach. Maybe this is left up to a face to face >> discussion at the meeting. >> Again, our goal is to take the FEState semantic and express >> it at the LFB instance level. >> With FEState there is an equivalent semantic at the coarse granularity >> of the FE i.e CE can update the config and when ready send a single >> message which says "activate" . How the isolation of the FE is >> achieved is up to the implementer. You describe isolation of the FE as >> being achieved by turning off physical ports on the datapath. I >> described an ASIC that could be sent a single message at the register >> level to achieve that same goal. >> As it stands right now, the interpretation of activate/deactivate >> is left up to the implementation. Thats where we draw our >> motivation. >> >> cheers, >> jamal >> >> >> >> On Mon, Oct 15, 2012 at 10:28 AM, Joel M. Halpern >> wrote: >>> >>> I have to strongly disagree. >>> >>> With regard to turning off physical ports, there are two reasons that >>> apply >>> to physical ports, and do not apply to the logical input ports of LFBs. >>> 1) This is a semantic that human beings express. >>> 2) More importantly, the upstream of these physical ports is in general >>> not >>> under the control of the CE. So the CE & FEs have to be prepared for it >>> doing unexpected things. >>> >>> With regard to CE operation, there is no need for admin-disabling port. >>> In >>> fact, doing so will add needless steps to the operation of setting up a >>> new >>> or changed configuration. When making any configuration change to LFBs, >>> the >>> CE has to >>> a) determine what changes it wants to make. For modifiable topologies, >>> this >>> may mean planning to create some LFB instances and / or planing to create >>> some links. For any FE, this will meaning determining what LFB >>> parameters >>> changes it wants to make. >>> b) The CE then evaluates the dependencies between this changes. It >>> arranges >>> them into a dependency graph. And then applies the changes from the root >>> of >>> the graph towards the leaves. If the CE does not do this, then there >>> will >>> be times when the FE will behave in unpredictable and probably >>> undesirable >>> ways. If the CE does do this, there is never a need to turn off an LFB >>> port. >>> >>> With regard to (b), if that sort can ot be done, the adding admin-disable >>> to >>> individual LFB logical input ports will not help make it possible. >>> >>> As a minor note, there are cases where, n order to preserve te dependency >>> properly, one may have to make certain temporary config changes. As a CE >>> coder, one can choose between the more complex math to find the stable >>> behavior or having the transient improper behavior. Again, the >>> admin-disable >>> will not help. >>> >>> I will admit that in the above I am assuming that it is irrelevant to try >>> to >>> determine the "meaning" of a topology and configuration in the middle of >>> a >>> change. With or without admin-disable on logical LFB input ports, such >>> interpretation of what was actually intended as a transient state is >>> probably very hard. >>> >>> Yours, >>> Joel >>> >>> PS: I am happy to discuss this in the meeting in Atlanta if we need to. >>> >>> >>> On 10/15/2012 6:47 AM, Jamal Hadi Salim wrote: >>>> >>>> >>>> On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> The issue of a non-modifiabe topology requires some though. In > my >>>>> experiece, one usually can't turn individual LFBs on and off >in such >>>>> setup. >>>>> Rather, with non-modifiable topologies the input >>>>> ports tot eh FE sre rutnred off, the whole set of LFBs is >configured, >>>>> and then the input ports are turned on. >>>> >>>> >>>> >>>> What you just described with "the input ports turned off" >>>> is essentially meant to be signalled by the FEO::FEState being put in >>>> AdminDisable. And i think in this case that would be an >>>> implementation approach (which is of course reasonable). >>>> There are ASICs where you dont have to turn off ports. >>>> You need to bang some registers to turn/off the datapath. >>>> And in that case I would rather set some bits in registers >>>> instead iterating the port list and turn off ports. >>>> >>>> If you assumed we can ignore non-modifiabe topology semantics, >>>> it still looks different and complex (youd have to scan the LFB >>>> topology and turn off every link to that LFB instance). >>>> It will solve one of our stated goals (the race condition aspect) >>>> but would be cumbersome for the HA aspect. >>>> >>>>> My big problem with turning off an LFB is that it is completely >>>>> unclear what it means for the packet flow. >>>> >>>> >>>> >>>> The semantics are the same as FEO::FEState >>>> If the FEState is Admin/OperDisable it provides the illusion that >>>> all LFB instances are inactive on the datapath. >>>> >>>>> What are we telling an upstream LFB to do >>>>> when the downstream LFB is disabled? Drop the packet? >>>>> Or is the CE >>>>> supposed to assume that disabled LFBs are transparent? Both choices >>>>> can >>>>> produce extremely improper behavior. >>>> >>>> >>>> >>>> Agreed - the FE advertising this capability must be able to handle >>>> the configuration. >>>> Implementation specific perhaps, but one way is to empty any >>>> control components related to the LFB instance from the datapath. >>>> In our case the FE would store the inactive Instance information in >>>> software >>>> (but not in the datapath) and activation implies storing it into the >>>> datapath. >>>> >>>>> Put differently, it is not at all clear to we that a instantiated, >>>>> connected, LFB can be meaningfully and safely disabled. >>>> >>>> >>>> >>>> It may end up being implementation specific as is the >>>> case of FEO::FEState. >>>> >>>> cheers, >>>> jamal >>>> >>> >> > From ehalep@gmail.com Wed Oct 17 04:37:58 2012 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 BF40521F8816 for ; Wed, 17 Oct 2012 04:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LKcPwZQ0fft for ; Wed, 17 Oct 2012 04:37:58 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1FF721F8815 for ; Wed, 17 Oct 2012 04:37:57 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so447160wib.13 for ; Wed, 17 Oct 2012 04:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=gRLatH/S8jOBdrX00yLM5rKdFBRZrAxwtKGXgeWQB+I=; b=z6HpjIW2QoZNi571HaTuhTWzvuYaFN/fDQAStdIQo0oyH7iR7lM7Kks9XErm47wCwD qaIACqNtgscKzzrXVoSbeTGC/LZ6igeMft01y3jGBjOXbNVGPWc8UjMVOWg520oTch/h ERSWxAHvIluYBF75JfmgEYm+n/8SH65pfhdioS3mUOS9I9xKllFdjRTY1Zd6mcrZ3yKy YDzx+OQttWn/+qzVB7PAQtVr9DFJdd3vZkHUZ9XMhhjO3nTMllUdzI4tX24iMHl4P3Mp tPSgOtX0jDZOw9iKkXn/QBdIO3f3NUm9y4GYF0KJIonbWgW3J6ZnP7i+YrABYC5PdPoW IxXg== Received: by 10.180.82.72 with SMTP id g8mr3090753wiy.20.1350473876781; Wed, 17 Oct 2012 04:37:56 -0700 (PDT) Received: from EhalepXPS (ppp046177014084.access.hol.gr. [46.177.14.84]) by mx.google.com with ESMTPS id q7sm27249517wiy.11.2012.10.17.04.37.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:37:55 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> <006101cda4d4$c498e970$4dcabc50$@com> In-Reply-To: Date: Wed, 17 Oct 2012 14:37:52 +0300 Message-ID: <00d801cdac5b$d8ca7240$8a5f56c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2lhSOXvtuL4bClRse++VG8F5n2UwG0nTng Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] Fwd: FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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, 17 Oct 2012 11:37:58 -0000 Greetings Jamal, Please see inline. Regards, Evangelos Haleplidis. > ---------- Forwarded message ---------- > From: Jamal Hadi Salim > Date: Mon, Oct 8, 2012 at 2:32 PM > Subject: Re: [forces] FW: New Version Notification for draft- > haleplidis-forces-model-extension-00.txt > To: Haleplidis Evangelos >=20 >=20 > Greetings Evangelos, >=20 > On Sun, Oct 7, 2012 at 5:43 PM, Haleplidis Evangelos = > wrote: >=20 > > [=C5=C7] Hm... why can't you have default values when the permission = is > > read-only? > > > > Counters could be read-only. The value of the read-only component = can > > be changed by the FE. > > I don't think that having a default value is a problem in this case. >=20 > I was going to say lets hear what Joel has to say - but my memory = cells > triggered: The FE can set whatever initial value it wishes - which may > be the default value. That is separate from what the CE can write to > it. > The permissions reflect what the CE can do to the component. > Having default values means in absence of the CE writing some value, > there will be something default written to the component. [=C5=C7] Isn't that what the default value is? In the absence of a CE = doing a SET, the FE sets a default value.=20 Do I miss something? >=20 > >> I think it would be a problem if the typeref was a complex struct. > > [=C5=C7] This is what the new draft is trying to push. > > I agree it may be a problem, but that problem can be encountered on > > the current model as well. > > At least in the new one, you could get a default value in a deeply > > nested component. >=20 > Can you provide an example of how that would work? > How would one describe a default for component foo.bar.goo.gah? > What i showed would work for foo.bar without any changes. >=20 [=C5=C7] Sorry but no. What you showed: foobar foobar foo foo uint32 1234 bar bar uint32 5678 Is not applicable with the current schema. This is only applicable: foobar foobar =09 foo foo uint32 bar bar uint32 value So, to answer your question on how to describe foo.bar.goo.gah, since default value is optional you can do even the following (added a doo and = gag as well): foobargoogah foo.bar.goo.gah foo foo bar bar goo goo gah gah uint32 0 =09 gag gag uchar =09 doo doo uchar 0 > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From ehalep@gmail.com Wed Oct 17 06:50:27 2012 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 99D4321F875B for ; Wed, 17 Oct 2012 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB0E6B-AyFMg for ; Wed, 17 Oct 2012 06:50:25 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C64721F8740 for ; Wed, 17 Oct 2012 06:50:25 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so4311203wgb.13 for ; Wed, 17 Oct 2012 06:50:24 -0700 (PDT) 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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=CaPtnIOOI/fEmrdB15LTsPLG9ZanXRxiP+evfls07fA=; b=UEGy0ueKc7PYJ8NujkiqeKzDqwktFXb8ZLEW3Z4AltTM0Ejdf00u21CettMFVPyp6L 2Gc6jKjOAv6MZXtga7X2YnMUwJQtwz5ui/AwQqJfsVSBVoJEdBimKNV3CVYpwdSslR1s bwBWvwKnfRidYYsGWdIdZ8etXIjIqmC357KOuAEMGPrQ2w2Hhzy266xbKf/cCn0DnitG 18UM/Lvi8M4dGfjy2oA6ZZFiiDStYNO1xldj7YFgc4CDJzRm5AOGvn3G77MgKrgibqsg KqQ2nEFlQCnD9Dr7xODL5B3NW0K5esrBMX20lwvybkkJWx7Em1o8INWqD3LCNzo53od/ jmtQ== Received: by 10.180.80.33 with SMTP id o1mr4316095wix.14.1350481824542; Wed, 17 Oct 2012 06:50:24 -0700 (PDT) Received: from EhalepXPS (ppp046177014084.access.hol.gr. [46.177.14.84]) by mx.google.com with ESMTPS id v3sm27734809wiy.5.2012.10.17.06.50.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:50:23 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Wed, 17 Oct 2012 16:50:20 +0300 Message-ID: <010601cdac6e$5a14e030$0e3ea090$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2sakInkzN9SOKSQIis538O4pQWewAA7Rkg Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-01.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, 17 Oct 2012 13:50:27 -0000 Greetings to the list, Just uploaded a new version of the model extension draft to answer = current comments. Most notable changes: 1. Removed Frame Produced as optional - considered an errata. 2. Removed optional default value of metadata. 3. Added text for strengthening validation to specify that is an = enhancement and not an extension. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, October 17, 2012 4:21 PM > To: ehalep@ece.upatras.gr > Subject: New Version Notification for draft-haleplidis-forces-model- > extension-01.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-model-extension-01.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-model-extension > Revision: 01 > Title: ForCES Model Extension > Creation date: 2012-10-17 > WG ID: Individual Submission > Number of pages: 28 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-model-extensi= on-01.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-model-extension > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-model-extension-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-model-extensio= n-01 >=20 > 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. >=20 > RFC5812 has been around for two years and experience in its use has > shown room for extensions without a need to alter the protocol = while > retaining backward compatibility with older xml libraries. >=20 >=20 >=20 >=20 > The IETF Secretariat From wmwang2001@hotmail.com Wed Oct 17 20:47:47 2012 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 CAAC111E80A6 for ; Wed, 17 Oct 2012 20:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+IpPeGDvGGV for ; Wed, 17 Oct 2012 20:47:47 -0700 (PDT) Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id EA7ED11E80A5 for ; Wed, 17 Oct 2012 20:47:46 -0700 (PDT) Received: from BLU0-SMTP339 ([65.55.111.135]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 20:47:45 -0700 X-Originating-IP: [60.186.178.0] X-EIP: [Ur58SCnFlH+GGfTMs63OMq9Q1ODTEbhX] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([60.186.178.0]) by BLU0-SMTP339.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 20:47:44 -0700 From: "Wang,Weiming" To: , References: <00e401cdaa31$f8545c10$e8fd1430$@olddog.co.uk> Date: Thu, 18 Oct 2012 11:47:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 18 Oct 2012 03:47:44.0309 (UTC) FILETIME=[54C0D650:01CDACE3] Subject: Re: [forces] The future of the ForCES WG 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, 18 Oct 2012 03:47:47 -0000 SSB3b25kZXIgaWYgaXQgd291bGQgaGF2ZSBiZWVuIGEgbW9yZSByZWFzb25hYmxlIHRpbWUgcG9p bnQgY2xvc2luZyB0aGUgV0cgYWJvdXQgIHR3byB0byB0aHJlZSB5ZWFycyBhZ28sIHJhdGhlciB0 aGFuIGF0IGN1cnJlbnQgcG9pbnQuIA0KDQpDdXJyZW50bHksIHRoZSB2YWx1ZSBvZiBGb3JDRVMg aXMgYmVpbmcgcmVkaXNjb3ZlcmVkIGFsb25nIHdpdGggdGhlIGluY3JlYXNpbmcgZGVtYW5kcyBh bmQgYWN0aXZpdGllcyB0b3dhcmRzIGEgbmV3IGR5bmFtaWMgYW5kIGZsZXhpYmxlIGVub3VnaCBu ZXR3b3JrIHN5c3RlbSBhbmQgYXNzb2NpYXRlZCBlcXVpcG1lbnRzLiBJbiB0aGUgcHJvY2Vzcywg bW9yZSB3b3JrIG9mIHRoZSBXRyBpcyBhbHNvIGZvdW5kIG5lY2Vzc2FyeS4gVGhlIHdvcmsgbWFp bmx5IGxpZXMgIGluIHRoZSBMMiBwcm9jZXNzaW5nIGFuZCByZWxhdGVkIGVudGl0aWVzIGluIHRo ZSBGb3JDRVMgbW9kZWwuIEN1cnJlbnRseSB0aGVyZSBhcmUgc2V2ZXJhbCBkcmFmdHMgYWRkcmVz c2luZyB0aGUgaXNzdWVzLiBNb3Jlb3ZlciwgYW4gTEZCIGxpYnJhcnkgZG9jdW1lbnQgc3BlY2lm aWNhbGx5ICBmb3IgTDIgcHJvY2Vzc2luZyBpcyBhbHNvIHJlcXVpcmVkLCB3aGljaCBpcyB3aGF0 IHdlIGFyZSBkb2luZyBhbmQgaG9wZSB0byBzdWJtaXQgYSBkcmFmdCBzb29uLiBJIGp1c3QgdGhp bmsgdGhlc2Ugd29ya3MgYXJlIGVzc2VuY2lhbCB0aGVuIHdlICJkZWNsYXJlIHN1Y2Nlc3Mgb2Yg dGhlIEZvckNFUyBXRyBhbmQgc2h1dCBpdCBkb3duIi4gVGhlIHByb2Nlc3MgdG8gZmluaXNoIHRo ZSB3b3JrIG1heSBub3QgbGFzdCBsb25nLCBzYXkgaGFsZiB0byBvbmUgeWVhciBhdCBtb3N0LiBT bywgY29tYXJlZCB3aXRoIDEwIHllYXJzIHRoZSBXRyBsYXN0ZWQsIEkgYmVsaWV2ZSBzdWNoIHBy b2xvbmdlZCBhIGxpdHRsZSB0aW1lIGlzIHJlYWxseSB2YWx1YWJsZSBhbmQgd29ydGh5IG9mIGl0 LiANCg0KdGhhbmtzLA0KV2VpbWluZw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQoNCj4gSGkgV0cs DQo+IA0KPiBUaGUgY2hhaXJzIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoZSBmdXR1cmUg b2YgdGhlIFdHIGZvciBhYm91dCBhIHllYXIuIFRoZQ0KPiB3b3JraW5nIGdyb3VwIHdvcmsgbG9h ZCBoYXMgYmVlbiBwcmV0dHkgbGlnaHQsIGFuZCBiZXR3ZWVuIG1lZXRpbmdzIHRoZSBtYWlsaW5n DQo+IGxpc3QgaGFzIGJlZW4gYWxtb3N0IGVudGlyZWx5IGRvcm1hbnQuDQo+IA0KPiBJbiBQYXJp cyB3ZSB3ZXJlIGFsbCBhIGJpdCBzdXJwcmlzZWQgYnkgdGhlIHR1cm4tb3V0IGF0IHRoZSBGb3JD RVMgbWVldGluZyBhbmQNCj4gdGhlIHN1ZGRlbiBpbnRlcmVzdCBpbiBjb21wYXJpbmcgRm9yQ0VT IHdpdGggT3BlbkZsb3cuIFNvIHdlIGRlY2lkZWQgdG8gbGV0DQo+IHRoaW5ncyBydW4gdW50aWwg VmFuY291dmVyIHRvIHNlZSB3aGF0IGhhcHBlbmVkLiANCj4gDQo+IEJldHdlZW4gUGFyaXMgYW5k IFZhbmNvdXZlciB0aGVyZSB3YXMgcHJldHR5IG11Y2ggc2lsZW5jZSwgYW5kIHNvIHRoZSBjaGFp cnMgYW5kDQo+IEkgYWdyZWVkIHRoYXQgd2Ugd291bGQgbWFrZSBzdXJlIGV2ZXJ5b25lIGtuZXcg dGhhdCB0aGV5IGNvdWxkIHBvc3QgSS1EcyBhbmQNCj4gZGlzY3VzcyAiZnJpbmdlIiBGb3JDRVMg dG9waWNzIG9uIHRoZSBsaXN0LiBKYW1hbCBzZW50IG1haWwgIm9wZW5pbmcgdGhvc2UNCj4gZ2F0 ZXMiIG9uIEF1Z3VzdCAxMi4gQnV0IHRoZSBsaXN0IHdhcyBzaWxlbnQuDQo+IA0KPiBTbyB3ZSBn b3QgdG8gZGlzY3Vzc2luZyB3aGF0IHdvdWxkIGhhcHBlbiBuZXh0Lg0KPiANCj4gTXkgcHJlZmVy cmVkIG9wdGlvbiBpcyB0byBkZWNsYXJlIHN1Y2Nlc3MgKHdlIGhhdmUgdGhlIGNvcmUgRm9yQ0VT IFJGQ3MpIGFuZA0KPiBjbG9zZSB0aGUgV0cuIFdlIHdvdWxkIGNvbXBsZXRlIHRoZSBleGlzdGlu ZyBXRyBJLURzIGFzIEFEIHNwb25zb3JlZCwgYW5kIGtlZXANCj4gdGhlIG1haWxpbmcgbGlzdCBv cGVuIGZvciBkaXNjdXNzaW9uIG9mIEZvckNFUyBpc3N1ZXMuDQo+IA0KPiBCdXQgSmFtYWwgKGdv b2QgY29wIHRvIG15IGJhZCBjb3ApIHBlcnN1YWRlZCBtZSB0byBsZXQgdGhlIFdHIHJ1biBhIGJp dCBtb3JlIGFuZA0KPiB0byBhbGxvdyBhIG1lZXRpbmcgaW4gQXRsYW50YS4gQW5kLCB0cnVlIHRv IGZvcm0sIHlvdSBndXlzIGhhdmUgbWFuYWdlZCB0byBwdXNoDQo+IG91dCBzb21lIG5ldyBkcmFm dHMganVzdCBiZWZvcmUgdGhlIGRlYWRsaW5lLg0KPiANCj4gU28gdGhpcyBpcyB3aGF0IHdlJ2xs IGRvLi4uDQo+IA0KPiBQbGVhc2UgdGhpbmsgb2YgdGhlIG1lZXRpbmcgaW4gQXRsYW50YSBhcyBh IHNvcnQgb2YgIkZvckNFUyBjb250aW51YXRpb24NCj4gbWluaS1Cb0YiDQo+IFdoYXQgd29yayBj b3VsZCB0aGUgd29ya2luZyBncm91cCBtb3ZlIG9uIHRvIChpbmNsdWRpbmcgZXhpc3RpbmcgSS1E cyk/IEFuZCB3aGF0DQo+IGlzIHRoZSBjb21taXRtZW50IHdpdGhpbiB0aGUgV0cgdG8gcHVzaCB0 aGlzIHdvcmsgZm9yd2FyZD8NCj4gDQo+IEkgbXVzdCBleHBsYWluIHRoYXQgbG9va2luZyBhdCB0 aGUgcHJvZ3Jlc3Mgb3ZlciB0aGUgbGFzdCAxMiBtb250aHMsIHRoZXJlDQo+IGRvZXNuJ3Qgc2Vl bSB0byBiZSBlbm91Z2ggZW5lcmd5IHRvIGNvbXBsZXRlIHRoZSBjdXJyZW50IFdHIGRyYWZ0cywg YW5kIHRoYXQNCj4gKGxhY2sgb2YpIHByb2dyZXNzIGNvbG9ycyBob3cgSSBsb29rIGF0IHRoZSBX Ry4gU28gcGxlYXNlIGRvIHlvdXIgYmVzdCB0byBwcm92ZQ0KPiBKYW1hbCByaWdodC4NCj4gDQo+ IFRoYW5rcywNCj4gQWRyaWFuDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZv cmNlc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Zv cmNlcw0KPg== From hadi@mojatatu.com Thu Oct 18 06:10:35 2012 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 05DBC21F872A for ; Thu, 18 Oct 2012 06:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-fABkSbwAiR for ; Thu, 18 Oct 2012 06:10:29 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF64D21F8723 for ; Thu, 18 Oct 2012 06:10:29 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so10342782oag.31 for ; Thu, 18 Oct 2012 06:10:29 -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:content-transfer-encoding:x-gm-message-state; bh=YEum9137m4Y4uFo0pg4+Oz6nTle760LptrP9M3MENMs=; b=i6gdC7Mnd7wiZ529zpyiwWEBSDYRm9Vijh6Db/e4iXekZk8yXrrrha+pA5XgESivg7 Z38nLElyXf/nM/gnwBV55V15TMwD4YZYbVSRjgRKk6GHhKZZhgC5V/aiiJduTjOs15F+ uJ00a3QwtumAS33B+CRGE64gOlgH1dWg0scIZbQlk2xIO/lQ3FIvwDP5/hkhyVX87gwp pgNR09jxZL1IH183utxXQ2yYAiOgA/eIhH6dmhCYenfati4zTcpnNQh4HaW5ZDBWQxCC O41T5khw7SIgrUGVvZYMOcx+KTMB6Wwg5GAe9kNEKaqdLkRKJ3FHeQo0X33+A0QMwr5k g9ww== Received: by 10.60.169.202 with SMTP id ag10mr19039356oec.84.1350565828884; Thu, 18 Oct 2012 06:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Thu, 18 Oct 2012 06:10:08 -0700 (PDT) In-Reply-To: <00d801cdac5b$d8ca7240$8a5f56c0$@com> References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> <006101cda4d4$c498e970$4dcabc50$@com> <00d801cdac5b$d8ca7240$8a5f56c0$@com> From: Jamal Hadi Salim Date: Thu, 18 Oct 2012 09:10:08 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk7L1UHjXXDxGMGfvqd+gAE0XfMLjKU4wNG5wzjkKLFACKTzNVGDawTe0fir0BQgD25X5lw Cc: forces@ietf.org Subject: Re: [forces] Fwd: FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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, 18 Oct 2012 13:10:35 -0000 Greetings Evangelos, On Wed, Oct 17, 2012 at 7:37 AM, Haleplidis Evangelos wr= ote: > [=C5=C7] Isn't that what the default value is? In the absence of a CE doi= ng a > SET, the FE sets a default value. > Do I miss something? As i recall the discussion was: If you have read-only ACL, the CE cant set anything - given permissions are on what _the CE can do_ i.e the point of reference is the CE not the FE. Example, capabilities are read-only by definition. Yes, the FE sets them but they dont have default values. > [=C5=C7] Sorry but no. > What you showed: > > foobar > foobar > > > foo > foo > uint32 > 1234 > > > bar > bar > uint32 > 5678 > > > > Is not applicable with the current schema. Why is it not applicable? A component can have a default value; even when it is embedded inside another component. >This is only applicable: > > foobar > foobar > > > foo > foo > uint32 > > > bar > bar > uint32 > > > value > If the schema insists on that - i believe it is unintended. Does the RFC text also say the same thing? cheers, jamal From ehalep@gmail.com Fri Oct 19 08:50:18 2012 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 89A2A21F8751 for ; Fri, 19 Oct 2012 08:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbEX3U6F8r4O for ; Fri, 19 Oct 2012 08:50:18 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6997521F874B for ; Fri, 19 Oct 2012 08:50:17 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so322881wgb.13 for ; Fri, 19 Oct 2012 08:50:16 -0700 (PDT) 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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=XP7ivTfeJMKiWbgGCwtp/I6QpIdaeVz8Hhbm3JvAhJk=; b=B5mDm6cfnoOsHwCROGb8zxQ+oE/9lGPB7LuHQRbvYWxzllCTof7MAUVN+IQFw0C8UH KpgWVO0Nd8DU41N9Kg6XqH6KAtXDTHospDaxb8598MoG0gHyeyE/y+fPYYJUPkDQOZ0L cE6PCCxklhCZXZSKadW/FYl+d6YRpIWAvmz/xThuL+43z1OaggX0umMauQgvzddTrTTE vZHg6bHOsnbM3CtdmuWfDSHBOoIBQMs26VIt1m0lEGlneIZtYIGKU7Sl91xgyigDkAwT KYEU+3ZZOjsyEzXirHPmAu5fE4zWgCLIbQ8YNk6jR6suhWATlioZ4JQku8MIWcV8LjDm s56Q== Received: by 10.216.207.103 with SMTP id m81mr989810weo.190.1350661815418; Fri, 19 Oct 2012 08:50:15 -0700 (PDT) Received: from EhalepXPS (ppp141237208110.access.hol.gr. [141.237.208.110]) by mx.google.com with ESMTPS id p4sm4101020wix.0.2012.10.19.08.50.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 08:50:02 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Fri, 19 Oct 2012 18:49:58 +0300 Message-ID: <011f01cdae11$65240970$2f6c1c50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2uEIziGBJuwuIMQTK6F88I/lfO+gAAAcaw Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-packet-parallelization-01.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: Fri, 19 Oct 2012 15:50:19 -0000 Greetings to the list, We have submitted a new version for the parallelization draft. A major change is that we removed the valid metadatum in order for the = merging metadata to be opaque to LFBs inside a parallel path. This will = allow backward compatibility with current defined LFBs. In order for the = merger to know that an error has occurred in a parallel path, it will = receive the packet/chunk from the InvalidIn port. This port will be = connected to exception output ports from LFBs in the path. Along with = the invalid packet/chunk it may be followed by a ExceptionID or = ValidateErrorID (defined in lfb-lib). Also we added some more counters for invalid packets/chunks. We now have = also counters per error IDs and a counter that keeps track of in how = many merges were all packet/chunks invalid. Also we made the parallel type a component in the splitter LFB, per = Jamal's comment. The parallel type will be sent forward to the merger = LFB as metadata. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, October 19, 2012 6:43 PM > To: ehalep@ece.upatras.gr > Cc: joel.halpern@ericsson.com > Subject: New Version Notification for draft-haleplidis-forces-packet- > parallelization-01.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-packet-parallelization- > 01.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-packet-parallelization > Revision: 01 > Title: ForCES Packet Parallelization > Creation date: 2012-10-19 > WG ID: Individual Submission > Number of pages: 28 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-packet-parall= elization-01.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-packet-paralleliz= ation > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-packet-parallelization= -01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-packet-paralle= lization-01 >=20 > 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. >=20 > Many network devices support parallel packet processing. This > document describes how ForCES can model a network device's > parallelization datapath. >=20 >=20 >=20 >=20 > The IETF Secretariat From ehalep@gmail.com Fri Oct 19 13:53:05 2012 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 122DB21F87B3 for ; Fri, 19 Oct 2012 13:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4baerXcmKDyk for ; Fri, 19 Oct 2012 13:53:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1E21F879D for ; Fri, 19 Oct 2012 13:53:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so461604wgb.13 for ; Fri, 19 Oct 2012 13:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lAJkf6wJr1DEHeevVQhhgnyRS3+LcIOuOE4uziOBDLY=; b=Ajv+sfmEXGgljtQDZd+mN+QqpSYxkrjbVu8EZHKO4nOijpmOq24Lj/P74Wk8Wb7JSA Rygb/Qb+Ngp+V6vryluNfeUgxt1Nx9SjPYx0AvUV1Jbrf+OQrEb19LHEnLfUO1MC1xOe nE1r/WZhuDsMDqxG24rCfTPdH3Bj5r+8YUnDxHHkPXKpk3KYxOwIo8XLsbHpPxji4tm+ ZIOhlSQVrwsCUGUxUyn2HWXebM53LYngYgz0RFSuI+aUIfOjQzJ3wC4atK2QyK4HKUYb tEAzjtAKetMzuG0gFvEJ03fSE3qWOswinQPbmB5CQFppErvy5BXuOWXA4bL08MkNOcrM Uvyw== Received: by 10.216.199.166 with SMTP id x38mr1483450wen.75.1350679978873; Fri, 19 Oct 2012 13:52:58 -0700 (PDT) Received: from EhalepXPS (ppp141237208110.access.hol.gr. [141.237.208.110]) by mx.google.com with ESMTPS id ei1sm5481795wid.7.2012.10.19.13.52.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 13:52:58 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> <006101cda4d4$c498e970$4dcabc50$@com> <00d801cdac5b$d8ca7240$8a5f56c0$@com> In-Reply-To: Date: Fri, 19 Oct 2012 23:52:53 +0300 Message-ID: <015801cdae3b$b6a60710$23f21530$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2tMgSOmIFPGCaJTdGw5QlqodighQBB0iqQ Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] Fwd: FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Fri, 19 Oct 2012 20:53:05 -0000 Greetings Jamal, > If the schema insists on that - i believe it is unintended. > Does the RFC text also say the same thing? >=20 [=C5=C7] The schema insists on that. The RFC text does not specify what = happens if there is a compound data structure. It simply says the defaultValue = is optional but at the component level. Now that I read the text more closely and in the defaultValue's light, I think that we MUST ensure that all read-reset components have a default value. How else would the FE know which value it should reset it to? Also, I have a question. In the model document it says: "The CE can read = and reset this resource, but cannot set it to an arbitrary value." Does this mean:=20 "When the CE reads the value, the value is reset" Or "The CE can either read or reset the value" If it's the first, I didn't find any reference in the text (I missed = it?) If it's the second, with what command will the CE reset the value of the read-reset component? Regards, Evangelos Haleplidis. From joel@stevecrocker.com Fri Oct 19 13:57:07 2012 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 F380021F876C for ; Fri, 19 Oct 2012 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJcv2ntdHDal for ; Fri, 19 Oct 2012 13:57:06 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5AE21F8753 for ; Fri, 19 Oct 2012 13:57:06 -0700 (PDT) Received: from [71.161.51.221] (account joel@stevecrocker.com HELO [10.10.10.104]) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 20898871; Fri, 19 Oct 2012 20:58:27 +0000 Message-ID: <5081BE9C.5000507@stevecrocker.com> Date: Fri, 19 Oct 2012 16:57:00 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Haleplidis Evangelos References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> <006101cda4d4$c498e970$4dcabc50$@com> <00d801cdac5b$d8ca7240$8a5f56c0$@com> <015801cdae3b$b6a60710$23f21530$@com> In-Reply-To: <015801cdae3b$b6a60710$23f21530$@com> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: forces@ietf.org Subject: Re: [forces] Fwd: FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Fri, 19 Oct 2012 20:57:07 -0000 Read only and read-rest values are set to whatever the FE wants. Default values are for things the CE should set, but might not. (For example, a default value for a counter makes no sense.) Yours, Joel On 10/19/2012 4:52 PM, Haleplidis Evangelos wrote: > Greetings Jamal, > >> If the schema insists on that - i believe it is unintended. >> Does the RFC text also say the same thing? >> > > [ลว] The schema insists on that. The RFC text does not specify what happens > if there is a compound data structure. It simply says the defaultValue is > optional but at the component level. > > Now that I read the text more closely and in the defaultValue's light, I > think that we MUST ensure that all read-reset components have a default > value. How else would the FE know which value it should reset it to? > > Also, I have a question. In the model document it says: "The CE can read and > reset this resource, but cannot set it to an arbitrary value." > > Does this mean: > "When the CE reads the value, the value is reset" > Or > "The CE can either read or reset the value" > > If it's the first, I didn't find any reference in the text (I missed it?) > If it's the second, with what command will the CE reset the value of the > read-reset component? > > > Regards, > Evangelos Haleplidis. > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Fri Oct 19 14:14:32 2012 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 C049C21F874E for ; Fri, 19 Oct 2012 14:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZfdd5SCwzVc for ; Fri, 19 Oct 2012 14:14:32 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0C21F845B for ; Fri, 19 Oct 2012 14:14:20 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1049531oag.31 for ; Fri, 19 Oct 2012 14:14:20 -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:content-transfer-encoding:x-gm-message-state; bh=3dgwFMdRrIJXyp+us/x6GKATd0myV3YF/mi1QUeIZo0=; b=lwMLzWXTzWcCvTRU1yr9CZl260UMkhsjy7XfKFGzQ7l6XpMSHsi9Do3A6PQwuyTJSG vExvMLik7fMZWsXfYw1F4FldsdQJx291leGU1fJH2WGa86+WZ9sK3rDPJqZVgHCayHQ/ 036eItXIoWCh+tOepH69VrX3/gyrdcUFlUtAriQP4o7pDLTZ+rkkb84fpkI05SEtmnZx lci1lzxCwc7zllMmuDttYLk8UyuljIq3LQwJScUTOKVHimUix63Q958GpbeLHayOJm87 nmLjO+nqBcz7tJN/sf32yy+0NGhX3yr6t0t0j31XrgkvHgUvzCOLs8HSXLefbWMnLdCY Kuxg== Received: by 10.60.26.72 with SMTP id j8mr2653005oeg.68.1350681260373; Fri, 19 Oct 2012 14:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Fri, 19 Oct 2012 14:14:00 -0700 (PDT) In-Reply-To: <015801cdae3b$b6a60710$23f21530$@com> References: <00ec01cda020$f1d0e810$d572b830$@com> <00a901cda08e$32af4580$980dd080$@com> <010701cda0e6$ed5ed5f0$c81c81d0$@com> <00a301cda232$b2216550$16642ff0$@com> <006101cda4d4$c498e970$4dcabc50$@com> <00d801cdac5b$d8ca7240$8a5f56c0$@com> <015801cdae3b$b6a60710$23f21530$@com> From: Jamal Hadi Salim Date: Fri, 19 Oct 2012 17:14:00 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk6UUJZEeFcJgV76pt6i/0ov3MO4XYchU6Kwyk23kshFpSBeBA5512fziy+jT693rn9ny1m Cc: forces@ietf.org Subject: Re: [forces] Fwd: FW: New Version Notification for draft-haleplidis-forces-model-extension-00.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: Fri, 19 Oct 2012 21:14:32 -0000 Greetings Evangelos, On Fri, Oct 19, 2012 at 4:52 PM, Haleplidis Evangelos wr= ote: > Greetings Jamal, > >> If the schema insists on that - i believe it is unintended. >> Does the RFC text also say the same thing? >> > > [=CE=95=CE=97] The schema insists on that. Definitely errata. >The RFC text does not specify what happens > if there is a compound data structure. It simply says the defaultValue is > optional but at the component level. Indeed - thats why i was saying it is harder do a complex struct's selectiv= e defaults if they were deeply nested (in the example i gave). > Now that I read the text more closely and in the defaultValue's light, I > think that we MUST ensure that all read-reset components have a default > value. How else would the FE know which value it should reset it to? > > Also, I have a question. In the model document it says: "The CE can read = and > reset this resource, but cannot set it to an arbitrary value." > > Does this mean: > "When the CE reads the value, the value is reset" > Or > "The CE can either read or reset the value" > > If it's the first, I didn't find any reference in the text (I missed it?) > If it's the second, with what command will the CE reset the value of the > read-reset component? > Traditional definition of read-reset is: when i read something you reset it= to 0. But i think it would be more powerful to be able to define a default val= ue (optionally) which defines a different reset value. cheers, jamal From ehalep@gmail.com Mon Oct 22 15:04:33 2012 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 3D71B21F84B2 for ; Mon, 22 Oct 2012 15:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejalYCH0OvVR for ; Mon, 22 Oct 2012 15:04:32 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF0111E8097 for ; Mon, 22 Oct 2012 15:04:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1803399wgb.13 for ; Mon, 22 Oct 2012 15:04:31 -0700 (PDT) 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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=RzvbLDknfZytTtVZfgpxfy4ZbQrfcKAM4xyMKJhB7M0=; b=qKCA/OqZXDZ/dLhihJUN2iJN8h4WGeQEgnjSvxh1aMLKE3xcU+EWV4Ol4MsOhcOJWu u2+zw7zGC7eIkE0KwfgoqHkQ8kJ163m9OxVqrWkgPmmkYBLuIs9Yv7UWUD4TY5LWr5nA Tn7CqXeomvgUfHu/NzRfqR0w6VhDcod8wkf3UDSv/1tMz4yVn2Ud9yGtE2SoAu3yURB0 4D3cWTo27yW5+kDGg9f1wmlREZ3Fa1ASVCyQ03NQ+PTOFFSjPgJohA+bUupF3nzr9F2E A/cGICqQ+v/yt2P0deiQj9wvYJX1eLmzv68NcCcFmu41gqnrujuhKJtpJK+n6mdNrsWQ Ysxw== Received: by 10.180.84.41 with SMTP id v9mr24195891wiy.8.1350943471261; Mon, 22 Oct 2012 15:04:31 -0700 (PDT) Received: from EhalepXPS (ppp079166023173.access.hol.gr. [79.166.23.173]) by mx.google.com with ESMTPS id j8sm53162909wiy.9.2012.10.22.15.04.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 15:04:30 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Tue, 23 Oct 2012 01:04:27 +0300 Message-ID: <00a501cdb0a1$35778160$a0668420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2woTudTCpDrdFeSUa6hydE28MasAAACGsA Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-openflow-lib-02.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: Mon, 22 Oct 2012 22:04:33 -0000 Greetings to the list, We have just updated the openflow library document. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, October 23, 2012 1:03 AM > To: ehalep@ece.upatras.gr > Cc: cherkaoui.omar@uqam.ca; wmwang@zjgsu.edu.cn; shares@ndzh.com > Subject: New Version Notification for = draft-haleplidis-forces-openflow- > lib-02.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-openflow-lib-02.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-openflow-lib > Revision: 02 > Title: Forwarding and Control Element Separation (ForCES) > OpenFlow Model Library > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 104 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-openflow-lib-= 02.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-openflow-lib > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-openflow-lib-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-openflow-lib-0= 2 >=20 > Abstract: > This document describes the OpenFlow switch in Logical Function > Blocks (LFBs) used in the Forwarding and Control Element Separation > (ForCES). The LFB classes are defined according to the ForCES > Forwading Element (FE) model and ForCES protocol specifications. > The > library includes the descriptions of the OpenFlow LFBs and the XML > definitions. >=20 >=20 >=20 >=20 > The IETF Secretariat From hadi@mojatatu.com Thu Oct 25 03:44:12 2012 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 8D78021F86E1 for ; Thu, 25 Oct 2012 03:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH2jja32GSZa for ; Thu, 25 Oct 2012 03:44:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83A21F8695 for ; Thu, 25 Oct 2012 03:44:12 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1619907obq.31 for ; Thu, 25 Oct 2012 03:44:11 -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=fPj1mBSp21RjIAO+LGgCIUgd7VuIcOahsOAw/d4r3No=; b=XZZsw8H9JkL1GhavuIJ1Dou75EvWeX1UF73ema1R1kbSMjKiFx4xESetpsbksmlyEG EjvwAnzJN/q5pPglOwrM0bm7RPNXksdGwP32J4TguOuu3WNMA0L6iVxzoVUy1EYB+xNj B7YagyiBIRDTa7xCktaQC2GS4hEjSKcWZrXBCfLrUv5RMZFoWHM+rxvNGxfLyPlWFOHW 8jtp/X7rf4q21ee4C0AETNFK54uQJwJ+sXVyIFd+Y8C//oYd/bHPvwaqwyt3yJ1Foq7z dDtK8JI0lGeeQc9zQZNRrQZFBYcuFFk/dVSbVDdgpXMNpG99nklvOqf2aX10NuKsrGd7 eeIw== Received: by 10.182.131.100 with SMTP id ol4mr15203454obb.38.1351161851472; Thu, 25 Oct 2012 03:44:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Thu, 25 Oct 2012 03:43:51 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 25 Oct 2012 06:43:51 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnC1TnOtxT+3AFvwCxNryHJb5k3yMT8w1XicBDJ4QnSzUsHIho9XeDc7W1sKKyqId3a2lux Subject: [forces] agenda uploaded 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, 25 Oct 2012 10:44:12 -0000 Folks, I have uploaded the agenda. As you can see the schedule is pretty tight. The focus is only on new work that is currently outside the charter. As per posting from our AD here: https://www.ietf.org/mail-archive/web/forces/current/msg04325.html if you are interested in the new work please show up at the meeting and express your interest. If you havent sent me a request, please dont unless it is new work. If you have sent me a request and you are not on that list and you still consider your request new work, please ping me (otherwise i plan to buy your forgiveness with a drink). cheers, jamal From hadi@mojatatu.com Thu Oct 25 15:10:56 2012 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 B3C9D21F88D0 for ; Thu, 25 Oct 2012 15:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.97 X-Spam-Level: X-Spam-Status: No, score=-102.97 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fSOepr7YVnj for ; Thu, 25 Oct 2012 15:10:55 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABEB521F88CE for ; Thu, 25 Oct 2012 15:10:55 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2372963oag.31 for ; Thu, 25 Oct 2012 15:10:55 -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=Nv+cOGvrpViPpps+ZHn+1I1jUxM9NF3JDPCUdb79zcw=; b=pVsVbBc4LwUOgw58o3po6bQi1jOiv7gnAunRWjqA4ILWhFmw+bDsUcWABMI0UhbJJB F5SMSjkhsFjf2trtLjdXHW4qtHBztv6Iysms+MO9EBbozPqGhBuNDTuVpigKrXYnuSsG b+Mh2poUFyXJsUYaHnkmdJCxzpSR44lPMJ9Vg860CrIYBRoS11xF4FBwohDDY5mCAcKP EOnkUdPB5W/cq8GGhwjTx7UjZEyMuqX0uYOhhhe7HDH9lN3ogyi9w8WSq0q59OXrPvgk oDHUk+ljNfSbpkqyJxP8fmXbwwMV6khaqeoGXvLUE3Pjat9nE82gFbZPJjwumJXczClC jjZw== Received: by 10.60.169.202 with SMTP id ag10mr18434613oec.84.1351203055047; Thu, 25 Oct 2012 15:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.95.226 with HTTP; Thu, 25 Oct 2012 15:10:34 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 25 Oct 2012 18:10:34 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/mixed; boundary=bcaec54c52fc1d95d104cce97acf X-Gm-Message-State: ALoCoQknRWdY8/V/ya+QV2YXROwDsHff1RnBt2fcE3MMI1LxfT170LKcy1APsPuM0O+52GYkPVYh Cc: Chuanhuang Li , Evangelos Haleplidis , Weiming Wang , Joel Halpern , forces@ietf.org Subject: [forces] PROTO shepherd write up for draft-ietf-forces-lfb-lib 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, 25 Oct 2012 22:10:56 -0000 --bcaec54c52fc1d95d104cce97acf Content-Type: text/plain; charset=ISO-8859-1 Adrian, Please find attached the proto writeup to kick start the publication process for draft-ietf-forces-lfb-lib. cheers, jamal --bcaec54c52fc1d95d104cce97acf Content-Type: text/plain; charset=US-ASCII; name="new-writeup-draft-ietf-forces-lfb-lib.txt" Content-Disposition: attachment; filename="new-writeup-draft-ietf-forces-lfb-lib.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8qfdhoh0 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLApJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/IFdoeSBpcwp0aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/IElzIHRoaXMg dHlwZSBvZiBSRkMgaW5kaWNhdGVkIGluIHRoZSB0aXRsZQpwYWdlIGhlYWRlcj8KClRoaXMgZG9j dW1lbnQgaXMgYSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgKFByb3Bvc2VkIFN0YW5kYXJkKS4K VGhlIHRpdGxlIHBhZ2Ugb2YgdGhlIGRyYWZ0IHJlZmxlY3RzIHRoaXMgUkZDIHR5cGUuIFRoZSBj aG9pY2UKb2Ygc3RhbmRhcmRzIHRyYWNrIGlzIGEgV0cgbWFuZGF0ZSB0byBwdWJsaXNoIGF0IGxl YXN0IG9uZSBMRkIKZG9jdW1lbnQuCgooMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50 IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50CldyaXRlLVVwLiBQbGVhc2UgcHJvdmlk ZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLgpSZWNlbnQgZXhhbXBsZXMg Y2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvcgphcHByb3ZlZCBk b2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2lu ZwpzZWN0aW9uczoKClRlY2huaWNhbCBTdW1tYXJ5OgpUaGlzIGRvY3VtZW50IGRlZmluZXMgYmFz aWMgY2xhc3NlcyBvZiBMb2dpY2FsIEZ1bmN0aW9uIEJsb2NrcyAoTEZCcykKdXNlZCBpbiB0aGUg Rm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykuICBUaGUK YmFzaWMgTEZCIGNsYXNzZXMgYXJlIGRlZmluZWQgYWNjb3JkaW5nIHRvIEZvckNFUyBGRSBtb2Rl bCBhbmQgRm9yQ0VTCnByb3RvY29sIHNwZWNpZmljYXRpb25zLCBhbmQgYXJlIHNjb3BlZCB0byBt ZWV0IHJlcXVpcmVtZW50cyBvZgp0eXBpY2FsIHJvdXRlciBmdW5jdGlvbnMgYW5kIGNvbnNpZGVy ZWQgYXMgdGhlIGJhc2ljIExGQiBsaWJyYXJ5IGZvcgpGb3JDRVMuICBUaGUgbGlicmFyeSBpbmNs dWRlcyB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBMRkJzIGFuZCB0aGUKWE1MIGRlZmluaXRpb25z LgoKV29ya2luZyBHcm91cCBTdW1tYXJ5OgpTdGFuZGFyZCBXRyBkaXNjdXNzaW9ucywgbm90aGlu ZyBjb250cm92ZXJzaWFsLgoKRG9jdW1lbnQgUXVhbGl0eToKVGhlcmUgYXJlIGtub3duIGltcGxl bWVudGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50LgpWZXJzaW9uIDAwIG9mIHRoaXMgZG9jdW1lbnQg d2FzIHB1Ymxpc2hlZCBpbiAyMDA5IGFuZCBoYXMgdW5kZXJnb25lCmZlZWRiYWNrIGJhc2VkIG9u IGltcGxlbWVudGF0aW9uIGFuZCBhcmNoaXRlY3R1cmUgZGlzY3Vzc2lvbi4KClBlcnNvbm5lbDoK SmFtYWwgSGFkaSBTYWxpbSBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQuIEFkcmlhbiBGYXJyZWwg aXMKdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuCgooMykgQnJpZWZseSBkZXNjcmliZSB0 aGUgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB3YXMgcGVyZm9ybWVkCmJ5IHRoZSBEb2N1 bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBpcyBub3QgcmVh ZHkKZm9yIHB1YmxpY2F0aW9uLCBwbGVhc2UgZXhwbGFpbiB3aHkgdGhlIGRvY3VtZW50IGlzIGJl aW5nIGZvcndhcmRlZCB0bwp0aGUgSUVTRy4KCkkgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBn YXZlIG51bWVyb3VzIGZlZWRiYWNrIGR1cmluZyBpdHMgbGlmZXRpbWUuCkkgdmFsaWRhdGVkIHRo ZSBYTUwgdXNlZC4gIEkgaGF2ZSBpbXBsZW1lbnRlZCB0aGlzIExGQiBhbmQgdmFsaWRhdGVkIApp dHMgZGVmaW5pdGlvbnMuCkEgY291cGxlIG9mIHNtYWxsIGNoYW5nZXMgZXhpc3Q7IHRoZXkgY291 bGQgYmUgYWRkZWQgYXQgCmRvY3VtZW50IHB1YmxpY2F0aW9uIHRpbWUuCgooNCkgRG9lcyB0aGUg ZG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yCmJy ZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCBoYXZlIGJlZW4gcGVyZm9ybWVkPwoKVGhlIGRvY3Vt ZW50IGhhcyBoYWQgYWRlcXVhdGUgcmV2aWV3LgpUaGUgZG9jdW1lbnQgaGFzIHVuZGVyZ29uZSBp bXBsZW1lbnRhdGlvbnMuCgooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2 aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb20KYnJvYWRlciBwZXJzcGVjdGl2ZSwgZS5nLiwg c2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIEFBQSwgRE5TLApESENQLCBYTUwsIG9y IGludGVybmF0aW9uYWxpemF0aW9uPyBJZiBzbywgZGVzY3JpYmUgdGhlIHJldmlldyB0aGF0CnRv b2sgcGxhY2UuCgpUaGUgc2hlcGhlcmQgaGFzIG5vIGNvbmNlcm5zLgoKKDYpIERlc2NyaWJlIGFu eSBzcGVjaWZpYyBjb25jZXJucyBvciBpc3N1ZXMgdGhhdCB0aGUgRG9jdW1lbnQgU2hlcGhlcmQK aGFzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9y IGFuZC9vciB0aGUKSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBz IGhlIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlCndpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9j dW1lbnQsIG9yIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseQppcyBhIG5lZWQgZm9y IGl0LiBJbiBhbnkgZXZlbnQsIGlmIHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3NlIGlzc3Vlcwph bmQgaGFzIGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1 bWVudCwgZGV0YWlsIHRob3NlCmNvbmNlcm5zIGhlcmUuCgpXZSB3ZXJlIHdhaXRpbmcgZm9yIG9u ZSBwZXJzb24gd2hvIHByb3ZpZGVkIGRvY3VtZW50IHJldmlldyB0bwpyZXNwb25kIHRvIHRoZSBh dXRob3JzLiBUaGUgc2hlcGhlcmQgZGVjaWRlZCB0byBnbyBhaGVhZCBhbmQgcHJvY2VlZCB3aXRo CnB1YmxpY2F0aW9uIHJlZ2FyZGxlc3Mgc2luY2UgdGhlIGluZGl2aWR1YWwgd2FzIGEgbGl0dGxl IGhhcmQgdG8gZ2V0IGhvbGQKb2Ygb3ZlciB0aGUgbGFzdCBmZXcgbW9udGhzLiBUaGVyZSBpcyBz dGlsbCBhbiBvcHBvcnR1bml0eSBvbiB0aGUgSUVURgp3aWRlIGxhc3QgY2FsbDsgdGhlIHNoZXBo ZXJkIHdpbGwgY29tbXVuaWNhdGUgd2l0aCB0aGUgcGVyc29uIHRvIG1ha2UKdGhlbSBhd2FyZSBv ZiB0aGlzLgoKKDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBh cHByb3ByaWF0ZSBJUFIgZGlzY2xvc3VyZXMKcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OQpoYXZlIGFscmVhZHkgYmVl biBmaWxlZC4gSWYgbm90LCBleHBsYWluIHdoeT8KClRoZXJlIGFyZSBubyBJUFIgaXNzdWVzIGRp c2Nsb3NlZCBvciBrbm93bi4gVGhlIHNoZXBoZXJkIHBvbGxlZCB0aGUKYXV0aG9ycy4KCig4KSBI YXMgYW4gSVBSIGRpc2Nsb3N1cmUgYmVlbiBmaWxlZCB0aGF0IHJlZmVyZW5jZXMgdGhpcyBkb2N1 bWVudD8gSWYKc28sIHN1bW1hcml6ZSBhbnkgV0cgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBy ZWdhcmRpbmcgdGhlIElQUiBkaXNjbG9zdXJlcy4KClRoZXJlIGlzIG5vIElQUiBpbnZvbHZlZC4K Cig5KSBIb3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8g RG9lcyBpdCByZXByZXNlbnQKdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlk dWFscywgd2l0aCBvdGhlcnMgYmVpbmcgc2lsZW50LApvciBkb2VzIHRoZSBXRyBhcyBhIHdob2xl IHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggaXQ/CgpUaGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0 aGUgZG9jdW1lbnQgaXMgc3Ryb25nLiAKCigxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFw cGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUKZGlzY29udGVudD8gSWYgc28sIHBs ZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlCmVtYWlsIG1l c3NhZ2VzIHRvIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGlu IGEKc2VwYXJhdGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkg YXZhaWxhYmxlLikKCk5vIG9uZSBoYXMgdGhyZWF0bmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2Ug aW5kaWNhdGVkIGV4dHJlbWUKZGlzY29udGVudC4KCjExKSBJZGVudGlmeSBhbnkgSUQgbml0cyB0 aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGluIHRoaXMKZG9jdW1lbnQuIChTZWUgaHR0 cDovL3d3dy5pZXRmLm9yZy90b29scy9pZG5pdHMvIGFuZCB0aGUgSW50ZXJuZXQtRHJhZnRzCkNo ZWNrbGlzdCkuIEJvaWxlcnBsYXRlIGNoZWNrcyBhcmUgbm90IGVub3VnaDsgdGhpcyBjaGVjayBu ZWVkcyB0bwpiZSB0aG9yb3VnaC4gCgpUaGVyZSBhcmUgYSBmZXcgbWlub3Igd2FybmluZyBuaXRz IHRoYXQgY291bGQgYmUgZml4ZWQgYmVmb3JlCnB1YmxpY2F0aW9uLiBUaGVyZSBhcmUgb2YgdHdv IHR5cGVzOgphKSAid2VpcmQgc3BhY2luZyIKYikgInVudXNlZCByZWZlcmVuY2UiCmMpIE5vdCBm b3VuZCBieSB0aGUgbml0cyB0b29sIGlzIHRoZSBmYWN0IHRoYXQgc2VjdGlvbiAzLjEKIG9uIGxp bmUgMjYxLCBhIHJlZmVyZW5jZSB0byBSRkM1ODEyIGlzIG1hZGUgd2hlbiBpdCBzaG91bGQgYmUK IGEgcmVmZXJlbmNlIHRvIFJGQzE4MTIgKG9ubHkgb2ZmIGJ5IDQwMDA7LT4pLgoKKDEyKSBEZXNj cmliZSBob3cgdGhlIGRvY3VtZW50IG1lZXRzIGFueSByZXF1aXJlZCBmb3JtYWwgcmV2aWV3IGNy aXRlcmlhLApzdWNoIGFzIHRoZSBNSUIgRG9jdG9yLCBtZWRpYSB0eXBlLCBhbmQgVVJJIHR5cGUg cmV2aWV3cy4KClRoZSBkb2N1bWVudCBoYXMgYW4gSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u IHRoYXQgaXMgYXBwcm9wcmlhdGVseQpmaWxsZWQgb3V0LiBJdCBkb2VzIG5vdCByZXF1aXJlIHJl dmlld3MgcmVsYXRlZCB0byBNSUJzLiAKCigxMykgSGF2ZSBhbGwgcmVmZXJlbmNlcyB3aXRoaW4g dGhpcyBkb2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXMgZWl0aGVyCm5vcm1hdGl2ZSBvciBpbmZv cm1hdGl2ZT8gCgp5ZXMuCkFsbCByZWZlcmVuY2VzIGFyZSBwcm9wZXJseSBzZXBhcmF0ZWQgYW5k IGxhYmVsbGVkLgoKKDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1l bnRzIHRoYXQgYXJlIG5vdCByZWFkeQpmb3IgYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBp biBhbiB1bmNsZWFyIHN0YXRlPyBJZiBzdWNoIG5vcm1hdGl2ZQpyZWZlcmVuY2VzIGV4aXN0LCB3 aGF0IGlzIHRoZSBwbGFuIGZvciB0aGVpciBjb21wbGV0aW9uPyAKCm5vLgoKKDE1KSBBcmUgdGhl cmUgZG93bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3 KT8gSWYKc28sIGxpc3QgdGhlc2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBB cmVhIERpcmVjdG9yIGluIHRoZQpMYXN0IENhbGwgcHJvY2VkdXJlLiAKCm5vLgoKKDE2KSBXaWxs IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRoZSBzdGF0dXMgb2YgYW55IGV4 aXN0aW5nClJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFk ZXIsIGxpc3RlZCBpbiB0aGUKYWJzdHJhY3QsIGFuZCBkaXNjdXNzZWQgaW4gdGhlIGludHJvZHVj dGlvbj8gSWYgdGhlIFJGQ3MgYXJlIG5vdCBsaXN0ZWQKaW4gdGhlIEFic3RyYWN0IGFuZCBJbnRy b2R1Y3Rpb24sIGV4cGxhaW4gd2h5LCBhbmQgcG9pbnQgdG8gdGhlIHBhcnQKb2YgdGhlIGRvY3Vt ZW50IHdoZXJlIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGUgb3RoZXIg UkZDcwppcyBkaXNjdXNzZWQuIElmIHRoaXMgaW5mb3JtYXRpb24gaXMgbm90IGluIHRoZSBkb2N1 bWVudCwgZXhwbGFpbiB3aHkKdGhlIFdHIGNvbnNpZGVycyBpdCB1bm5lY2Vzc2FyeS4KClRoZSBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IHdpbGwgbm90IGNoYW5nZSB0aGUgc3RhdHVzIG9m IGFueQpleGlzdGluZyBSRkNzLgoKKDE3KSBEZXNjcmliZSB0aGUgRG9jdW1lbnQgU2hlcGhlcmQn cyByZXZpZXcgb2YgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMKc2VjdGlvbiwgZXNwZWNpYWxseSB3 aXRoIHJlZ2FyZCB0byBpdHMgY29uc2lzdGVuY3kgd2l0aCB0aGUgYm9keSBvZgp0aGUgZG9jdW1l bnQuIENvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHRoZSBkb2N1bWVu dAptYWtlcyBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSByZXNlcnZhdGlvbnMg aW4gSUFOQSByZWdpc3RyaWVzLgpDb25maXJtIHRoYXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdp c3RyaWVzIGhhdmUgYmVlbiBjbGVhcmx5IGlkZW50aWZpZWQuCkNvbmZpcm0gdGhhdCBuZXdseSBj cmVhdGVkIElBTkEgcmVnaXN0cmllcyBpbmNsdWRlIGEgZGV0YWlsZWQKc3BlY2lmaWNhdGlvbiBv ZiB0aGUgaW5pdGlhbCBjb250ZW50cyBmb3IgdGhlIHJlZ2lzdHJ5LCB0aGF0IGFsbG9jYXRpb25z CnByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zIGFyZSBkZWZpbmVkLCBhbmQgYSBy ZWFzb25hYmxlIG5hbWUKZm9yIHRoZSBuZXcgcmVnaXN0cnkgaGFzIGJlZW4gc3VnZ2VzdGVkIChz ZWUgUkZDIDUyMjYpLiAKClRoaXMgZG9jdW1lbnQgYWRkcyB0byBleGlzdGluZyBGb3JDRVMgSUFO QSByZWdpc3RyaWVzIGFuZAppbnRyb2R1Y2VzIG5ldyByZWdpc3Rlcmllcy4KSXQgYWRkcyBkZWZp bml0aW9ucyB0byBMRkIgQ2xhc3MgTmFtZXMgYW5kIExGQiBDbGFzcyBJZGVudGlmaWVycwpyZWdp c3RlcnkuCkl0IGFkZHMgMyBuZXcgcmVnaXN0ZXJpZXMgZm9yIGhvbGRpbmc6CmEpIE1ldGFkYXRh IElELCBiKSBFeGNlcHRpb24gSUQgYW5kIGMpIFZhbGlkYXRlIEVycm9yIElELgoKKDE4KSBMaXN0 IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvciBm dXR1cmUKYWxsb2NhdGlvbnMuIFByb3ZpZGUgYW55IHB1YmxpYyBndWlkYW5jZSB0aGF0IHRoZSBJ RVNHIHdvdWxkIGZpbmQgdXNlZnVsCmluIHNlbGVjdGluZyB0aGUgSUFOQSBFeHBlcnRzIGZvciB0 aGVzZSBuZXcgcmVnaXN0cmllcy4gCgpJQU5BIGV4cGVydCByZXZpZXcgaXMgcmVxdWlyZWQgZm9y IHRoZSBuZXcgcmVnaXN0ZXJpZXMgZGVzY3JpYmVkIGluICMxNyAKYWJvdmUuCgooMTkpIERlc2Ny aWJlIHJldmlld3MgYW5kIGF1dG9tYXRlZCBjaGVja3MgcGVyZm9ybWVkIGJ5IHRoZSBEb2N1bWVu dApTaGVwaGVyZCB0byB2YWxpZGF0ZSBzZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBp biBhIGZvcm1hbApsYW5ndWFnZSwgc3VjaCBhcyBYTUwgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVm aW5pdGlvbnMsIGV0Yy4KClRoZSBYTUwgZGVmaW5pdGlvbnMgaGF2ZSBiZWVuIHZldHRlZCBieSB2 YXJpb3VzIFhNTCB2YWxpZGF0b3JzCmFnYWluc3QgdGhlIEZvckNFUyBtb2RlbCBzY2hlbWEuClRo ZSBYTUwgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnQgaGFzIGFsc28gYmVlbiB2ZXJpZmllZCBieSBh bgphbiBpbXBsZW1lbnRhdGlvbnMgaW4gd2hpY2ggdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBi ZWVuIGludm9sdmVkLgoK --bcaec54c52fc1d95d104cce97acf--