From damascene.joachimpillai@verizon.com Fri Mar 1 06:11:36 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2161321F9110 for ; Fri, 1 Mar 2013 06:11:36 -0800 (PST) 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 aBCGEdZLsTi7 for ; Fri, 1 Mar 2013 06:11:35 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 476B221F8519 for ; Fri, 1 Mar 2013 06:11:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 01 Mar 2013 14:11:06 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.84,761,1355097600"; d="scan'208";a="422342458" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 01 Mar 2013 14:11:06 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Fri, 1 Mar 2013 09:11:05 -0500 To: 'Jamal Hadi Salim' , "Joel M. Halpern" Date: Fri, 1 Mar 2013 09:11:05 -0500 Thread-Topic: [forces] InterFE Packet metadata Thread-Index: Ac4VLsyo9gWI/77WR7GMgPZvfhcr5QBV7+Cg Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> References: <512E4013.9030205@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: forces Subject: Re: [forces] InterFE Packet metadata 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, 01 Mar 2013 14:11:36 -0000 Are we planning on getting an EtherType registered for FoRCES interFE messa= ges? -- DJ -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Jamal Hadi Salim Sent: Wednesday, February 27, 2013 4:09 PM To: Joel M. Halpern Cc: forces Subject: Re: [forces] InterFE Packet metadata Ok, I finally got what Joel was alluding to. We _cant_ tell the content by looking at the REDIRECT-DATA TLV. The assumption is the receiver knows what the data is. Strangely enough, we= havent run into any issues in our implementation - I suppose because we on= ly have one source of redirected data and we know what it is at the receive= r. We should be able to define a metadata type which specifies this. Not sure if lfblib would be the right place to do this. cheers, jamal On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wrote= : > We have a REDIRECT-DATA TLV (0x116) which is for the packet data. > The METADATA TLV (0x115) carries the metadata. > > cheers, > jamal > > On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern w= rote: >> While discussing a related topic with someone else, I wondered about=20 >> something. In the redirect TLV (and presumably also in the inter-FE=20 >> packet >> transfer) we say taht the metadata indicates what kind of packet is=20 >> being transferred. >> But I don't think we ever actually defined the packet-type metadatum.=20 >> We have packet types in the dataplane flow, but that is not a piece=20 >> of metadata. >> have I forgotten something obvios, or do we have a gap? (We can=20 >> easily fix it in the lfb-library if we have a gap.) >> >> Yours, >> Joel >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Fri Mar 1 06:19:39 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15C21E805D for ; Fri, 1 Mar 2013 06:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 1U9PCTxiUpTj for ; Fri, 1 Mar 2013 06:19:38 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 73ECA21E8091 for ; Fri, 1 Mar 2013 06:19:38 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so363021vbb.23 for ; Fri, 01 Mar 2013 06:19:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=oUc3dphGoJXqxtcL63kxm72GMWji4uYOvtyJNqO52Rc=; b=nN8nVTh1bg+NKWTSeS7npfF5b6zOYS2OLmVUM4Qg2QPJelvQRILPiMt4PugetlNT9R BenmTIVugE95denJH1yZvs5nE72ulq36VaI/CNVL2Veh/uFaAotwt9D0ntwEXaiB0s55 UQoDXEz6QkKxuqV6jHKX/Lzl/YUvbDIcjEvxL2tgeskCHiefZuDOxFWWtUqTN5NHsFMg aEHWqJaJUHjalWLinaP5JAlXVJ8qiH2Gpm5RaRY04wIfU3/rD57b6oRpUa/kmlsN1eSv JwlOUZD/IsqZv2ei1EKga9ZbNtxN8H3Qdog0DajBHFVokZA9L9zn75xkD29EhS1As7Hu vsiQ== X-Received: by 10.220.150.11 with SMTP id w11mr4014175vcv.63.1362147577853; Fri, 01 Mar 2013 06:19:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.237.170 with HTTP; Fri, 1 Mar 2013 06:19:17 -0800 (PST) In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> References: <512E4013.9030205@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> From: Jamal Hadi Salim Date: Fri, 1 Mar 2013 09:19:17 -0500 Message-ID: To: "Joachimpillai, Damascene M" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlN/HeLG8Ni2IDAreMybItJalajmRawyvLa7f1WScYq2rb3mDwkZktqjNXeDzVoNriqcjtY Cc: "Joel M. Halpern" , forces Subject: Re: [forces] InterFE Packet metadata 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, 01 Mar 2013 14:19:39 -0000 In my opinion for ethernet transport we would need one registered. cheers, jamal On Fri, Mar 1, 2013 at 9:11 AM, Joachimpillai, Damascene M wrote: > Are we planning on getting an EtherType registered for FoRCES interFE messages? > > -- DJ > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, February 27, 2013 4:09 PM > To: Joel M. Halpern > Cc: forces > Subject: Re: [forces] InterFE Packet metadata > > Ok, I finally got what Joel was alluding to. > We _cant_ tell the content by looking at the REDIRECT-DATA TLV. > The assumption is the receiver knows what the data is. Strangely enough, we havent run into any issues in our implementation - I suppose because we only have one source of redirected data and we know what it is at the receiver. > We should be able to define a metadata type which specifies this. > Not sure if lfblib would be the right place to do this. > > cheers, > jamal > > On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wrote: >> We have a REDIRECT-DATA TLV (0x116) which is for the packet data. >> The METADATA TLV (0x115) carries the metadata. >> >> cheers, >> jamal >> >> On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern wrote: >>> While discussing a related topic with someone else, I wondered about >>> something. In the redirect TLV (and presumably also in the inter-FE >>> packet >>> transfer) we say taht the metadata indicates what kind of packet is >>> being transferred. >>> But I don't think we ever actually defined the packet-type metadatum. >>> We have packet types in the dataplane flow, but that is not a piece >>> of metadata. >>> have I forgotten something obvios, or do we have a gap? (We can >>> easily fix it in the lfb-library if we have a gap.) >>> >>> Yours, >>> Joel >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Fri Mar 1 06:50:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F7921F9184 for ; Fri, 1 Mar 2013 06:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, 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 jq5eO2WEN1He for ; Fri, 1 Mar 2013 06:50:39 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8707421F918C for ; Fri, 1 Mar 2013 06:50:39 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so2967643veb.13 for ; Fri, 01 Mar 2013 06:50:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=cu1JWdKs22j3JV61HBMdRzEtGO8BTAzdeYqN7/HENvU=; b=UweCXIHGrhcrYk7/u3Qcn/ZtLSiOPKfKTxbsiK3l/2vFbU++oBWrUl+x06Ga6grKSY MPhX3Guxe9wVUH4ZzkQ34EJYHJujwReQuNIifGT6lfO5YKxnsYK2kP+8iHkLHtv9Ynb5 Vv0Cocqba245hAOMqIeqIYqOcLIwOmIst7htrEBi0NwRfbDvaLToIEURmK+CSFqplqJB q/utJ8753Z41pHFK+XYSU/D8hN2xbzZROxzUc4ezgvMe23L/lCQqUW8uj3rJgZGPdmCt 4wS2R45XX9YAxt8Cc7LbcrfR1F64sZSaEIiODt0A4q/eNRfT/4RKVYTm2iZ+f0MtBzSR pqYg== X-Received: by 10.221.1.144 with SMTP id nq16mr471080vcb.57.1362149438710; Fri, 01 Mar 2013 06:50:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.237.170 with HTTP; Fri, 1 Mar 2013 06:50:18 -0800 (PST) From: Jamal Hadi Salim Date: Fri, 1 Mar 2013 09:50:18 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkIOOqFmSgfYE/8wY4RkNbNefvUTE+c3RsgvneWE9zgDMoO9Q8EnCMbq+oFXuvS9lv7bqLW Subject: [forces] preliminary 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: Fri, 01 Mar 2013 14:50:40 -0000 The draft agenda has been uploaded. We are currently exceeding our allocated time; so i expect to cut off some time for some presentations - apologies in advance. cheers, jamal From jmh@joelhalpern.com Fri Mar 1 08:40:52 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DECC21E8091 for ; Fri, 1 Mar 2013 08:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, 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 wKv-CBpcxq62 for ; Fri, 1 Mar 2013 08:40:51 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D7CEF21E808A for ; Fri, 1 Mar 2013 08:40:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B8DDB1C0C7A; Fri, 1 Mar 2013 08:40:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2B2841C0A84; Fri, 1 Mar 2013 08:40:49 -0800 (PST) Message-ID: <5130D9FD.5080805@joelhalpern.com> Date: Fri, 01 Mar 2013 11:40:29 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Joachimpillai, Damascene M" References: <512E4013.9030205@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces Subject: Re: [forces] InterFE Packet metadata 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, 01 Mar 2013 16:40:52 -0000 Assuming that we go down a path of not using a transport protocol to carry these (and I would prefer that path), then we either use an IP encapsulation (we could use IP fragmentation) or use an Ethertype. I tend to prefer the ethertype approach, but I can imagine folks arguing for either one. Yours, Joel On 3/1/2013 9:11 AM, Joachimpillai, Damascene M wrote: > Are we planning on getting an EtherType registered for FoRCES interFE messages? > > -- DJ > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, February 27, 2013 4:09 PM > To: Joel M. Halpern > Cc: forces > Subject: Re: [forces] InterFE Packet metadata > > Ok, I finally got what Joel was alluding to. > We _cant_ tell the content by looking at the REDIRECT-DATA TLV. > The assumption is the receiver knows what the data is. Strangely enough, we havent run into any issues in our implementation - I suppose because we only have one source of redirected data and we know what it is at the receiver. > We should be able to define a metadata type which specifies this. > Not sure if lfblib would be the right place to do this. > > cheers, > jamal > > On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wrote: >> We have a REDIRECT-DATA TLV (0x116) which is for the packet data. >> The METADATA TLV (0x115) carries the metadata. >> >> cheers, >> jamal >> >> On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern wrote: >>> While discussing a related topic with someone else, I wondered about >>> something. In the redirect TLV (and presumably also in the inter-FE >>> packet >>> transfer) we say taht the metadata indicates what kind of packet is >>> being transferred. >>> But I don't think we ever actually defined the packet-type metadatum. >>> We have packet types in the dataplane flow, but that is not a piece >>> of metadata. >>> have I forgotten something obvios, or do we have a gap? (We can >>> easily fix it in the lfb-library if we have a gap.) >>> >>> Yours, >>> Joel >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From damascene.joachimpillai@verizon.com Fri Mar 1 11:59:48 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5842721F8B84 for ; Fri, 1 Mar 2013 11:59:48 -0800 (PST) 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 EPktkEDXNO3U for ; Fri, 1 Mar 2013 11:59:47 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFE821F8B77 for ; Fri, 1 Mar 2013 11:59:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 01 Mar 2013 19:59:46 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.84,762,1355097600"; d="scan'208";a="428368961" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 01 Mar 2013 19:59:46 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Fri, 1 Mar 2013 14:59:46 -0500 To: "'Joel M. Halpern'" Date: Fri, 1 Mar 2013 14:59:45 -0500 Thread-Topic: [forces] InterFE Packet metadata Thread-Index: Ac4Wm7e3mFTxKKUkRhi2BRHQn1ofhQAG3LHA Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500B9@FHDP1LUMXC7V31.us.one.verizon.com> References: <512E4013.9030205@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> <5130D9FD.5080805@joelhalpern.com> In-Reply-To: <5130D9FD.5080805@joelhalpern.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: forces Subject: Re: [forces] InterFE Packet metadata 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, 01 Mar 2013 19:59:48 -0000 Do you think it will be good to register an ethertype and make it available= for use. If people choose to use IP to avoid and/or to deal with fragmenta= tion they could.=20 -- DJ -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Friday, March 01, 2013 11:40 AM To: Joachimpillai, Damascene M Cc: 'Jamal Hadi Salim'; forces Subject: Re: [forces] InterFE Packet metadata Assuming that we go down a path of not using a transport protocol to carry = these (and I would prefer that path), then we either use an IP encapsulatio= n (we could use IP fragmentation) or use an Ethertype. I tend to prefer th= e ethertype approach, but I can imagine folks arguing for either one. Yours, Joel On 3/1/2013 9:11 AM, Joachimpillai, Damascene M wrote: > Are we planning on getting an EtherType registered for FoRCES interFE mes= sages? > > -- DJ > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On=20 > Behalf Of Jamal Hadi Salim > Sent: Wednesday, February 27, 2013 4:09 PM > To: Joel M. Halpern > Cc: forces > Subject: Re: [forces] InterFE Packet metadata > > Ok, I finally got what Joel was alluding to. > We _cant_ tell the content by looking at the REDIRECT-DATA TLV. > The assumption is the receiver knows what the data is. Strangely enough, = we havent run into any issues in our implementation - I suppose because we = only have one source of redirected data and we know what it is at the recei= ver. > We should be able to define a metadata type which specifies this. > Not sure if lfblib would be the right place to do this. > > cheers, > jamal > > On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wro= te: >> We have a REDIRECT-DATA TLV (0x116) which is for the packet data. >> The METADATA TLV (0x115) carries the metadata. >> >> cheers, >> jamal >> >> On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern = wrote: >>> While discussing a related topic with someone else, I wondered about=20 >>> something. In the redirect TLV (and presumably also in the inter-FE=20 >>> packet >>> transfer) we say taht the metadata indicates what kind of packet is=20 >>> being transferred. >>> But I don't think we ever actually defined the packet-type metadatum. >>> We have packet types in the dataplane flow, but that is not a piece=20 >>> of metadata. >>> have I forgotten something obvios, or do we have a gap? (We can=20 >>> easily fix it in the lfb-library if we have a gap.) >>> >>> Yours, >>> Joel >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From joel@stevecrocker.com Fri Mar 1 12:02:17 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A274521E819A for ; Fri, 1 Mar 2013 12:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] 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 QSo2qz7K-Swa for ; Fri, 1 Mar 2013 12:02:16 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id DF9C421E8157 for ; Fri, 1 Mar 2013 12:02:13 -0800 (PST) Received: from dummy.name; Fri, 01 Mar 2013 20:02:12 +0000 Message-ID: <51310930.9090701@stevecrocker.com> Date: Fri, 01 Mar 2013 15:01:52 -0500 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Joachimpillai, Damascene M" References: <512E4013.9030205@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> <5130D9FD.5080805@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500B9@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500B9@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Joel M. Halpern'" , forces Subject: Re: [forces] InterFE Packet metadata 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, 01 Mar 2013 20:02:17 -0000 We have to decide what we want to put in the I-D for encapsulation. I hope we can agree on one encapsulation. When we have agreed, and the IESG agrees to publish, then if it needs an Ethertype we can get one. (There are plenty of easy ways to use experimental code points for development work.) We should not try to register one before then. Yours, Joel On 3/1/2013 2:59 PM, Joachimpillai, Damascene M wrote: > Do you think it will be good to register an ethertype and make it available for use. If people choose to use IP to avoid and/or to deal with fragmentation they could. > > -- DJ > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, March 01, 2013 11:40 AM > To: Joachimpillai, Damascene M > Cc: 'Jamal Hadi Salim'; forces > Subject: Re: [forces] InterFE Packet metadata > > Assuming that we go down a path of not using a transport protocol to carry these (and I would prefer that path), then we either use an IP encapsulation (we could use IP fragmentation) or use an Ethertype. I tend to prefer the ethertype approach, but I can imagine folks arguing for either one. > > Yours, > Joel > > On 3/1/2013 9:11 AM, Joachimpillai, Damascene M wrote: >> Are we planning on getting an EtherType registered for FoRCES interFE messages? >> >> -- DJ >> >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >> Behalf Of Jamal Hadi Salim >> Sent: Wednesday, February 27, 2013 4:09 PM >> To: Joel M. Halpern >> Cc: forces >> Subject: Re: [forces] InterFE Packet metadata >> >> Ok, I finally got what Joel was alluding to. >> We _cant_ tell the content by looking at the REDIRECT-DATA TLV. >> The assumption is the receiver knows what the data is. Strangely enough, we havent run into any issues in our implementation - I suppose because we only have one source of redirected data and we know what it is at the receiver. >> We should be able to define a metadata type which specifies this. >> Not sure if lfblib would be the right place to do this. >> >> cheers, >> jamal >> >> On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wrote: >>> We have a REDIRECT-DATA TLV (0x116) which is for the packet data. >>> The METADATA TLV (0x115) carries the metadata. >>> >>> cheers, >>> jamal >>> >>> On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern wrote: >>>> While discussing a related topic with someone else, I wondered about >>>> something. In the redirect TLV (and presumably also in the inter-FE >>>> packet >>>> transfer) we say taht the metadata indicates what kind of packet is >>>> being transferred. >>>> But I don't think we ever actually defined the packet-type metadatum. >>>> We have packet types in the dataplane flow, but that is not a piece >>>> of metadata. >>>> have I forgotten something obvios, or do we have a gap? (We can >>>> easily fix it in the lfb-library if we have a gap.) >>>> >>>> Yours, >>>> Joel >>>> _______________________________________________ >>>> forces mailing list >>>> forces@ietf.org >>>> https://www.ietf.org/mailman/listinfo/forces >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From damascene.joachimpillai@verizon.com Fri Mar 1 12:04:50 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B70521E80C6 for ; Fri, 1 Mar 2013 12:04:50 -0800 (PST) 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 A6k9kxelE0U5 for ; Fri, 1 Mar 2013 12:04:49 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 10D0321E803F for ; Fri, 1 Mar 2013 12:04:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 01 Mar 2013 20:04:36 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.84,762,1355097600"; d="scan'208";a="428373706" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 01 Mar 2013 20:04:35 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 1 Mar 2013 15:04:35 -0500 To: 'Joel' Date: Fri, 1 Mar 2013 15:04:35 -0500 Thread-Topic: [forces] InterFE Packet metadata Thread-Index: Ac4Wt6z0cmKgXAljTRy747O+J5gn9gAAE6iA Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500BC@FHDP1LUMXC7V31.us.one.verizon.com> References: <512E4013.9030205@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500AD@FHDP1LUMXC7V31.us.one.verizon.com> <5130D9FD.5080805@joelhalpern.com> <689CE984BDBA8B4CAF3EA6E2CDC5CACB0116D500B9@FHDP1LUMXC7V31.us.one.verizon.com> <51310930.9090701@stevecrocker.com> In-Reply-To: <51310930.9090701@stevecrocker.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Joel M. Halpern'" , forces Subject: Re: [forces] InterFE Packet metadata 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, 01 Mar 2013 20:04:50 -0000 Ok thanks.=20 -----Original Message----- From: Joel [mailto:joel@stevecrocker.com]=20 Sent: Friday, March 01, 2013 3:02 PM To: Joachimpillai, Damascene M Cc: 'Joel M. Halpern'; forces Subject: Re: [forces] InterFE Packet metadata We have to decide what we want to put in the I-D for encapsulation. I hope= we can agree on one encapsulation. When we have agreed, and the IESG agrees to publish, then if it needs an Et= hertype we can get one. (There are plenty of easy ways to use experimental= code points for development work.) We should not try to register one befo= re then. Yours, Joel On 3/1/2013 2:59 PM, Joachimpillai, Damascene M wrote: > Do you think it will be good to register an ethertype and make it availab= le for use. If people choose to use IP to avoid and/or to deal with fragmen= tation they could. > > -- DJ > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, March 01, 2013 11:40 AM > To: Joachimpillai, Damascene M > Cc: 'Jamal Hadi Salim'; forces > Subject: Re: [forces] InterFE Packet metadata > > Assuming that we go down a path of not using a transport protocol to carr= y these (and I would prefer that path), then we either use an IP encapsulat= ion (we could use IP fragmentation) or use an Ethertype. I tend to prefer = the ethertype approach, but I can imagine folks arguing for either one. > > Yours, > Joel > > On 3/1/2013 9:11 AM, Joachimpillai, Damascene M wrote: >> Are we planning on getting an EtherType registered for FoRCES interFE me= ssages? >> >> -- DJ >> >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On=20 >> Behalf Of Jamal Hadi Salim >> Sent: Wednesday, February 27, 2013 4:09 PM >> To: Joel M. Halpern >> Cc: forces >> Subject: Re: [forces] InterFE Packet metadata >> >> Ok, I finally got what Joel was alluding to. >> We _cant_ tell the content by looking at the REDIRECT-DATA TLV. >> The assumption is the receiver knows what the data is. Strangely enough,= we havent run into any issues in our implementation - I suppose because we= only have one source of redirected data and we know what it is at the rece= iver. >> We should be able to define a metadata type which specifies this. >> Not sure if lfblib would be the right place to do this. >> >> cheers, >> jamal >> >> On Wed, Feb 27, 2013 at 1:22 PM, Jamal Hadi Salim wr= ote: >>> We have a REDIRECT-DATA TLV (0x116) which is for the packet data. >>> The METADATA TLV (0x115) carries the metadata. >>> >>> cheers, >>> jamal >>> >>> On Wed, Feb 27, 2013 at 12:19 PM, Joel M. Halpern = wrote: >>>> While discussing a related topic with someone else, I wondered=20 >>>> about something. In the redirect TLV (and presumably also in the=20 >>>> inter-FE packet >>>> transfer) we say taht the metadata indicates what kind of packet is=20 >>>> being transferred. >>>> But I don't think we ever actually defined the packet-type metadatum. >>>> We have packet types in the dataplane flow, but that is not a piece=20 >>>> of metadata. >>>> have I forgotten something obvios, or do we have a gap? (We can=20 >>>> easily fix it in the lfb-library if we have a gap.) >>>> >>>> Yours, >>>> Joel >>>> _______________________________________________ >>>> forces mailing list >>>> forces@ietf.org >>>> https://www.ietf.org/mailman/listinfo/forces >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Thu Mar 7 03:53:50 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0A21F8D2E for ; Thu, 7 Mar 2013 03:53:50 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3WDyT0CAKSd for ; Thu, 7 Mar 2013 03:53:49 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 932C521F8D2C for ; Thu, 7 Mar 2013 03:53:49 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id 15so277567vea.28 for ; Thu, 07 Mar 2013 03:53:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=/d/GPSxCSlWuv7gYMZFyFWFUsnry5/0Z3xxO92aMFzc=; b=BOZ7uwocbhSZq4l4kd3Y/KjzkXE/YWCSbENRPAPiyoR4RBkbf05e4JJMCyuBBjt/lj +RojO9rWZUNIAtSfIJ0RC0guwHsgPNMlIk+MtRTlOAkTNfhlmGv5SJWH82OVYVAWDWEz www7YIE4xZ1ofsJLRZ+Fj1trYsxUoxH41wtmwZlyUawoEdczUvjqFm/FM4xI70hPIV1D IO4KrHkFz8uae/xLP/7OPDV8U22234qTxYJLTmZbMld27ljO0/FsU9vxf1ayylzhx2wy aAfeRzOAKwvZL2ryc4mVdf4/QqCksa2Sz5fDz2Tc46p/D94D8PwvLYpbzdkIiXds9QlG MH+g== X-Received: by 10.58.164.1 with SMTP id ym1mr6910681veb.43.1362657228718; Thu, 07 Mar 2013 03:53:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.248.164 with HTTP; Thu, 7 Mar 2013 03:53:28 -0800 (PST) From: Jamal Hadi Salim Date: Thu, 7 Mar 2013 06:53:28 -0500 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl5rroMK5TqNeD4d2d53DiE3pm7UXGq2SfaLP+7N220ERvjM4LmCAjuT3KlJOd6EiHPdFrQ Subject: [forces] orlando meeting 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, 07 Mar 2013 11:53:50 -0000 The new agenda has been uploaded. One new item has been added on a proposal for on multi-CE writers to an FE. This was poll question #11. There is a strong push from a deployment perspective to have this feature - for this reason a slot has been allocated to try and make the case for its inclusion in any possible new work. Please show up on time as the schedule is tight and we need to star as soon as we can. For remote users - this time we will have meetcho so slides/audio/chat can be shared in realtime. Also looking for volunteers for a minute taker and a scribe. cheers, jamal From hadi@mojatatu.com Mon Mar 11 07:36:06 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F22721F8B6C for ; Mon, 11 Mar 2013 07:36:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY60V+9V9Fcz for ; Mon, 11 Mar 2013 07:36:05 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7721F8B6D for ; Mon, 11 Mar 2013 07:36:05 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id p16so2138554vcq.29 for ; Mon, 11 Mar 2013 07:36:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=R8w+Ay6Q4kp0vaCxiT8w8s9T5w2wuU9Y25NmK5V3dyY=; b=S1fcL5NHX0yM0In4MN256pQecP/ULjNW9WEiSyte6fpsy+rAvwhz7X6E8BqXMLBbUI Ui4Jm+tGB8huwcBP4HjoT3kQ3VpS50NgWMXDbhX3KknB0RVTiPp/dfKQJ6HMoR9+tQZo 7wRWJUtLUzUw6mKmVQm5RMNI83g6t5T382ISEIEfLbWruyeJouZcA+BhOcAheLI4/y6J YQ3YHp4eBBwVNzzcpP5mZXdoPae7MzBV+y/wbiAvBNEsVW3YTbO6JYdDRsXQWWvj1XGj KdjMiOu7g5dHMFCB/yxT+WOLwZZTMziG8jwj3Cu1pRNdSaiD7GYnuWfXNBGUBTFyJWVo Iupw== X-Received: by 10.52.24.229 with SMTP id x5mr4319234vdf.84.1363012564828; Mon, 11 Mar 2013 07:36:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.137 with HTTP; Mon, 11 Mar 2013 07:35:43 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 11 Mar 2013 10:35:43 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlNjxcPsbQssafGEXVj0tl/MovPoKb7c63ze3HdR3uI90GN5CMBwWeuyy9gwO934clxDp0Q Subject: [forces] updated agenda + remote participation, etc 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, 11 Mar 2013 14:36:06 -0000 The agenda has been updated. More time has been allocated for upfront discussion before the presentations. Again, very tight agenda which happens to fall just before the social; please come early. For remote participants (wilfully ripped-off from the I2RS list): We have a meetecho session set-up for our meeting; the tutorial about how to use meetcho is at: http://ietf86.conf.meetecho.com/index.php/Tutorials I was hoping to try it out myself - but havent had time; We have a scribe volunteer already. A jabber scribe would be helpful as well. cheers, jamal From hadi@mojatatu.com Tue Mar 12 08:47:19 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8D211E80E7 for ; Tue, 12 Mar 2013 08:47:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAsKj5CHLlPT for ; Tue, 12 Mar 2013 08:47:18 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 83C9711E80E2 for ; Tue, 12 Mar 2013 08:47:18 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so3635488veb.13 for ; Tue, 12 Mar 2013 08:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=N5/TGJEM6YYHWy/Dqdz0X5uKsOGixLjMiGsZTUEqm98=; b=YQlnOgOObIjnyD24HDkUM9uIU/go2WYQCwmOmFiq3zrRlg9pGGjuA8wI5KqUi2DIng Om6cXOrF5/1AYx7lcDj5tDRTzRyyj9CCpTxiDbLs00B+dFYZBK0RmIXIs8Wu5EVISBhY DDW9SQEw3xH/aOqtF9kauQ67Zmls6Wy6jMiD6JziZ42jvzSQxlp2sql8aqhdZg//zqUn O8gxkPB7sdNPbdhtw/UBLh9KnJa5wsB+A2Ei7cIH5wFNugiNL+td8RnKVV7Kk+3c2rHy t+0xa4cH/iFS/vVMPHYYNiR1FeWliodiPc2LlfxaLGIe05ODO0W4jJB76MbLQnqFU8F/ JYKQ== X-Received: by 10.52.36.234 with SMTP id t10mr5839254vdj.95.1363103237867; Tue, 12 Mar 2013 08:47:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.137 with HTTP; Tue, 12 Mar 2013 08:46:57 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 12 Mar 2013 11:46:57 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmqEmwaWbh/JyZqicbyLAoPMr9TxHcNMlPTosSrKOeizADhLx34LNE6eBbNw3eml+5kzIzH Subject: [forces] Re-charter text 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, 12 Mar 2013 15:47:20 -0000 Please find below the proposed re-charter text up for discussion today. Comments/feedback welcome. cheers, jamal ---- Description of Working Group: This working group focuses on the ForCES architecture. The ForCES architecture constitutes: * One or more Control Elements (CE) interacting with one or more Forwarding Elements (FEs) to form a Network Element (NE). Any or all of these entities could be physical or virtual. *a data model to define the controlled or configured entity *a protocol used to communicate between CEs and FEs which is agnostic to the model used * one or more xml documents describing the controlled entity using the ForCES data model. The protocol acts (in the direction of the controller to datapath) on these definitions to achieve an end goal of control, configuration, packet redirect and in the reverse direction for responses, packet redirects and events. This working group was originally started to address the desire to create a standardized control-datapath architecture to control off-the shelf hardware that implements IP forwarding plane capability. This could be commercial chips, ASICs, FPGAs, Network Processors, or software based forwarding plane devices. As the work evolved, in order to avoid prejudicing implementation choices an abstract data model for the forwarding elements and a protocol for manipulating those forwarding elements was developed and standardized. Implementations and interoperation were demonstrated. With the emergence of SDN as an industry focus, there is renewed interest in the control capabilities and data plane flexibility provided by the ForCES architecture. Also, with this interest in SDN there has been a realization that the same abstractions can be used for service manipulation for overall device control or for configuration of the devices. The ForCES working group is now working on a set of additions to the model and protocol and libraries based on the experience gained from developing the standards and from many efforts using this architecture. In addition to the specific work items described below, it is understood that there are a number of external activities which may have interactions with the ForCES work. Discussions of how to use ForCES to model topics of interest to Network Function Virtualization, I2RS, or OpenFlow may be discussed and reviewed, although primary responsibility for such documents is likely to live in other working groups, individual contributions, or other standards bodies. The following 5 work items are the chartered tasks of this working group: o Model Extensions and protocol: This work is to address a set of extensions to the base model and protocol resulting in updates to RFCs 5810 and 5812. This effort will produce 2 standards effort documents (one for the model and another for the protocol). The model extensions will: 1. Allow complex metadata. 2. Allow optional default values for datatypes 3. Allow optional access-type for datatypes inside complex components 4. Define new base type: Bitmap The protocol extension will: 1. Table range query. 2. Table append 3. Additional return codes to reduce ambiguity o Inter-FE Connectivity: It has been found that ForCES processing often needs to be spread across multiple FEs. The original framework identified this as the Fi interface. Protocol and LFB mechanisms to carry metadata across this Fi interface are now needed. This effort will produce a standards track doument defining the protocol on the wire to address this need, and the LFBs used to represent the interfaces for sending and receiving such information. o Inter-FE Connectivity: It has been found that ForCES processing often needs to be spread across multiple FEs. The original framework identified this as the Fi interface. Protocol and LFB mechanisms to carry metadata across this Fi interface are now needed. This effort will produce a standards track doument defining the protocol on the wire to address this need, and the LFBs used to represent the interfaces for sending and receiving such information. o Paralellization: While in theory an FE can implement an LFB chain with paralellization, the current mechanism has no means to represent when synchronization is needed, or to allow the CE to specify where it believes such paralllism is useful. This work item will produce a single standards track document to improve the handling of this case. o Subsidiary Management: Deployment experience has demonstrated usefulness of expressing the FEM with the same semantics as any other LFB and thus be controlled by the CE. This work item assumes the presence of an initially booted FE whose configuration could then be updated at runtime via an FEM LFB for runtime config purposes (eg adding a new CE and its associated IP address). This work item can also be useful in addressing control of virtual FEs where individual FEM Managers can be addressed to control the creation, configuration, and resource assignment of such virtual FEs within a physical FE. This work would result in a standards track LFB FEM library RFC. Goals and Milestones September 2013 Request for Publication of Standards Track documents specifying model and protocol changes Feb 2014 Request for publication of Subsidiary management LFB March 2014 Request for publication of Inter-FE LFB and parallelization LFBs April 2014 Shutdown? From ietf@meetecho.com Tue Mar 12 16:03:32 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7933A21F8CB4 for ; Tue, 12 Mar 2013 16:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwhuwvVXF3Yh for ; Tue, 12 Mar 2013 16:03:32 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6872121F8CAC for ; Tue, 12 Mar 2013 16:03:31 -0700 (PDT) Received: from dell-tcastaldi ([130.129.130.228]) by smtpcmd02.ad.aruba.it with bizsmtp id An3S1l00M4voso201n3UiQ; Wed, 13 Mar 2013 00:03:29 +0100 Date: Tue, 12 Mar 2013 19:03:24 -0400 (EDT) From: Meetecho Team To: forces@ietf.org Message-ID: <4916061.1.1363129404761.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363129404690" Subject: [forces] FORCES session recording available 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, 12 Mar 2013 23:03:32 -0000 ------=_Part_0_2614099.1363129404690 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the FORCES WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#FORCES In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363129404690-- From hadi@mojatatu.com Wed Mar 13 03:16:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7121F8CEA for ; Wed, 13 Mar 2013 03:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n09XIBTxeaHm for ; Wed, 13 Mar 2013 03:16:24 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9F21F8CE8 for ; Wed, 13 Mar 2013 03:16:24 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id l22so400881vbn.0 for ; Wed, 13 Mar 2013 03:16:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=HYwxo1mDi1tgNS5D/A/zXk9Klr/EYmyOPMMflmM9rTg=; b=SjeE2lKDIuJFERCY3sHdsEJZuzjZDpsFaTVNuCnh3ut70KmZAtryEVrtWSJJL0Dcx9 o/PX2naNF0HoSMvgzAW2AKtrUpb1c8BbHYpsWzpZQRUAwGv6XfEps777/AOLgc+blL10 veAzHR31GlokTAOMTwLNo9BHyY4Fa6KVJhI80q+VZ3oqaB28MAtiAGaUDdfb0LmmPMnj nFrW+TOSLOvX81ck7G52so0PYKWLTuXOIVQAv8eLcIQUC9nMHfoOxWYh7G3uxRn8XmPe juSaWV7fSi/GCVrbb42WgjPGQgIVqcOoPtiRqWKRsK8mXP0+z4sTjczk1tlR/nOFr7m5 eWAA== X-Received: by 10.52.22.74 with SMTP id b10mr6932090vdf.96.1363169783524; Wed, 13 Mar 2013 03:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.137 with HTTP; Wed, 13 Mar 2013 03:16:03 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 13 Mar 2013 06:16:03 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn6K7aMnJ8QlnXrk3Z7N4FKkEoLWTdV/X8ILMy/S+4CwnfjIk/xvGHpKKJHiAmO6FOmMEI1 Subject: [forces] Recharter 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, 13 Mar 2013 10:16:25 -0000 Folks, We have a recharter! Thanks to Adrian and everyone in the WG who worked hard to get us here. The strawman charter was posted yesterday, the wording is highly likely to change. Please provide comments on the wording etc. cheers, jamal From hadi@mojatatu.com Thu Mar 14 09:42:05 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772DA11E80E9 for ; Thu, 14 Mar 2013 09:42:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIrwMQE8sMX2 for ; Thu, 14 Mar 2013 09:42:05 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8911E80B8 for ; Thu, 14 Mar 2013 09:42:04 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz10so1852101veb.21 for ; Thu, 14 Mar 2013 09:42:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=QqvvFnzM5Ldy6Q7C7agrMO6rXt5aKEqN9cgml1djxoc=; b=BCGDEnyTkXbhVWThnbxtUWiqL8XgtWyf288CWNFDCbIuspK4rMZvATUqhjBcw7riJ1 gUffDktnU7y9wUR/6PEP+anuK07JLf+5bUwdB6yrXAkLVopgemWeaS+kNkRYpuU27lKU cqhkhzQKBesMqq7M1SPYBBNinjrKqCcV5oS9Ka+L8Q5GtNmM+VFgSZgve877LFn5o67g DaXd36J+/RRL/d00YjmSCEY9IKr2PwtqqRRBaUedOmZmTaApTjgSlTvWBthaS6aEcs3Z t+VwG0aBBlaCpTqSD3WzClblx1CD83cLOg9Ak1UIQvyJBfS+SbgrLVjcMTfy40qLs6Nh 0xmg== X-Received: by 10.52.176.38 with SMTP id cf6mr2196613vdc.132.1363279323935; Thu, 14 Mar 2013 09:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.137 with HTTP; Thu, 14 Mar 2013 09:41:43 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 14 Mar 2013 12:41:43 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlo1bDIefax808Fihu0RNvPwCFLsC83DoDw+oLt9ZylDUKrtZM7dqWOwSEAZJ7x2eNsW7I8 Subject: [forces] sdnrg 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, 14 Mar 2013 16:42:05 -0000 Not that people familiar with ForCES need it, but: I am giving a quick talk on intro to ForCES at the SDNRG meeting at 13:00 cheers, jamal From internet-drafts@ietf.org Sat Mar 16 06:37:50 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB821F8C00; Sat, 16 Mar 2013 06:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSEIZWlQI2GT; Sat, 16 Mar 2013 06:37:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0D21F8BF1; Sat, 16 Mar 2013 06:37:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130316133749.16645.23999.idtracker@ietfa.amsl.com> Date: Sat, 16 Mar 2013 06:37:49 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-lfb-lib-11.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, 16 Mar 2013 13:37:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Logical Function Block (LFB) Library Author(s) : Weiming Wang Evangelos Haleplidis Kentaro Ogawa Chuanhuang Li Halpern Joel Filename : draft-ietf-forces-lfb-lib-11.txt Pages : 114 Date : 2013-03-16 Abstract: This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-lfb-lib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-lfb-lib-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmwang2001@hotmail.com Sat Mar 16 06:48:51 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6121F8936 for ; Sat, 16 Mar 2013 06:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMuTS7ipd4Wi for ; Sat, 16 Mar 2013 06:48:50 -0700 (PDT) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by ietfa.amsl.com (Postfix) with ESMTP id 67C6C21F8922 for ; Sat, 16 Mar 2013 06:48:50 -0700 (PDT) Received: from BLU0-SMTP454 ([65.55.111.136]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Mar 2013 06:48:50 -0700 X-EIP: [EwUCItbYKTo5kWU8/oSpgvEbequQRGmm] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([125.120.82.108]) by BLU0-SMTP454.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Mar 2013 06:48:47 -0700 From: "Wang,Weiming" To: Date: Sat, 16 Mar 2013 21:48:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 16 Mar 2013 13:48:47.0998 (UTC) FILETIME=[FBEFD1E0:01CE224C] Subject: [forces] Fw: New Version Notification - draft-ietf-forces-lfb-lib-11.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, 16 Mar 2013 13:48:51 -0000 SGksDQoNClRoZSBkb2N1bWVudCBoYXMgYmVlbiB1cGRhdGVkIHRvIHZlcnNpb24gKC0xMSkgYWNj b3JkaW5nIHRvIHJlcXVpcmVtZW50IGZyb20gQUQgYmFzZWQgb24gcmVzcG9uc2UgZnJvbSBJRVRG IGxhc3QgY2FsbCBvbiB0aGUgdmVyc2lvbiAoLTEwKS4gIA0KDQpUaGUgc3Vic3RhbnRpYWwgbW9k aWZpY2F0aW9uIGlzIHRoZSAiU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24uIA0KDQp0 aGFua3MgYSBsb3QuDQoNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpUbzogPGZvcmNlcy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYkB0b29scy5pZXRmLm9yZz47 IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KU2VudDogU2F0dXJkYXksIE1hcmNoIDE2LCAyMDEzIDk6 MzcgUE0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtZm9y Y2VzLWxmYi1saWItMTEudHh0DQoNCg0KDQpBIG5ldyB2ZXJzaW9uICgtMTEpIGhhcyBiZWVuIHN1 Ym1pdHRlZCBmb3IgZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYjoNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWItMTEudHh0DQoNClN1 YiBzdGF0ZSBoYXMgYmVlbiBjaGFuZ2VkIHRvIEFEIEZvbGxvd3VwIGZyb20gUmV2aXNlZCBJRCBO ZWVkZWQNCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGlzIEludGVybmV0LURy YWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1mb3Jj ZXMtbGZiLWxpYi8NCg0KRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQpodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWZvcmNlcy1sZmItbGliLTExDQoNCklFVEYg U2VjcmV0YXJpYXQuDQoNCg== From ehalep@gmail.com Sun Mar 17 06:45:24 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2064621F88D8 for ; Sun, 17 Mar 2013 06:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orX0gUfAStQO for ; Sun, 17 Mar 2013 06:45:23 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD5121F8574 for ; Sun, 17 Mar 2013 06:45:23 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id d10so2133513eaj.17 for ; Sun, 17 Mar 2013 06:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=DBuVrWC6XAiv0f/zRr/7G7CCDpI1AmLyoHbAVgTtntc=; b=oRZbHn3PBIC3KGFcZ5nC8EuqoGIDt41bxQ/VCkasSk6hFRXs5VAP4bk3AYlg7iCWAa ofB58Vr5xwFFLrmwxN+vG/mI4+taBhK4XzFZH+Ks5om0rHa2wnsCpmg4Xp+6x3s6CHD2 xmiREmrUjsA0d0jb+FZZ34fBy9o6+NHfwjYKM9yXozr+q/CLaYKOm5eIr4rpddDibGXD 7g/vlcpuzw2ImC8SCJlBSuliI/3Jty+Ad58hKpEnRMZUg0G52ubecxsqHynpdXgXsmu/ Oqteptj8MqoStgbVuqPHAorqsd/gN4DX4a/L192KpM5ZzzB0jTbX/i20qkQoPL5uuX0L suEQ== X-Received: by 10.15.43.132 with SMTP id x4mr38702469eev.31.1363527915496; Sun, 17 Mar 2013 06:45:15 -0700 (PDT) Received: from EhalepXPS (ppp141237205061.access.hol.gr. [141.237.205.61]) by mx.google.com with ESMTPS id h5sm21530194eem.1.2013.03.17.06.45.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Mar 2013 06:45:14 -0700 (PDT) From: "Haleplidis Evangelos" To: References: In-Reply-To: Date: Sun, 17 Mar 2013 15:45:08 +0200 Message-ID: <000f01ce2315$a6d5d500$f4817f00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4f1JaRCdQepcFPSJO0gYcXluyKRQDP37Eg Content-Language: el Subject: Re: [forces] Recharter 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, 17 Mar 2013 13:45:24 -0000 Greetings to the list, Just a few minor comments: 1. For the model extension please add: "5. Define new events to monitor states" This is for having in mind to add "Becomes Equal To" and probably "Becomes Not Equal To". 1. Change a bit the wording in: "The protocol extension will" To "The protocol extensions will" And in the numbers under change the wording to probably" "1. Define a table range query" "2. Define a table append" "3. Define additional..." 3. For the protocol extension also please add: "4. Define data packing rule for bitmap datatype". Although a suggestion is defined in the model, this detail should reside in the protocol document. 4. The Inter-FE Connectivity is written twice - delete one. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Wednesday, March 13, 2013 12:16 PM > To: forces@ietf.org > Subject: [forces] Recharter > > Folks, > > We have a recharter! > Thanks to Adrian and everyone in the WG who worked hard to get us here. > The strawman charter was posted yesterday, the wording is highly likely > to change. > Please provide comments on the wording etc. > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From dave.hood@ericsson.com Sun Mar 17 09:15:54 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D321F8C49 for ; Sun, 17 Mar 2013 09:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd9C5nu3eNi8 for ; Sun, 17 Mar 2013 09:15:54 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0321F8B35 for ; Sun, 17 Mar 2013 09:15:53 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-3f-5145ec38080e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 85.AB.02430.83CE5415; Sun, 17 Mar 2013 17:15:53 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Sun, 17 Mar 2013 12:15:52 -0400 From: Dave Hood To: "forces@ietf.org" Thread-Topic: Comment: draft-haleplidis-forces-model-extension-01 Thread-Index: Ac4jKaoHqZ9bWJwbTxCuci5rYmP6FA== Date: Sun, 17 Mar 2013 16:15:51 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA6405F4E875@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4E875eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyuXRPoK7lG9dAg3XLWCwevpnN5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ5vLxkLWj0rOleZNTA+cehi5OSQEDCRWHt9PzuELSZx4d56 ti5GLg4hgSOMEufWvWSGcJYzSjRtXMMMUsUmoCHx5NJkJhBbREBdYvXNbWwgtrCAjcS9Z02M EHFHiXkvDrN0MXIA2XoS7VdtQMIsAqoS12e+ASvnFfCVmLd4J9hIRqDF30+tARvJLCAucevJ fCaIgwQkluw5zwxhi0q8fPyPFcJWlljyZD/YeGaBfInmRZwQIwUlTs58wjKBUWgWkkmzEKpm IamCKNGRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxlsYgSG/DEJNt0djHte Wh5ilOZgURLnDXK9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsX6ve/niq0m7VRfmVDdM CjQ9+m3Negn5sFnNTz6LPJB50zH13qK8sE+RO373HmLeueE2/0YjoRJZ3SQjgUenK8XFGxv7 nzp96gr9klK1aOJTs4Dlz/8e0d/xSl9x77/PRzL+cKsy8RTOKH4p/jRgacwHmZNncl99/LfM csq9TBPFw+ZWW7YzX1RiKc5INNRiLipOBADBZgnKRwIAAA== Subject: [forces] Comment: draft-haleplidis-forces-model-extension-01 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, 17 Mar 2013 16:15:54 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4E875eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The abstract and intro say that there are new extensions, but do not give u= s a clue what they are. Brevity is good, but it is also helpful to know fro= m the beginning what the remainder of a document contains. Present text (introduction): The ForCES Model [RFC5812] presents a formal way to define FEs Logical Function Blocks (LFBs) using XML. [RFC5812] has been published a litlte more than two years and current experience in its use has shown some room for adding new and changing existing modeling concepts. This document extends the ForCES Model by changing and adding new concepts. These extensions do not require any changes on the ForCES protocol [RFC5810] as they are simply changes of the schema definition. Additionally backward compatibility is ensured as xml libraries produced with the earlier schema are still valid with the new one. Proposed text: The ForCES Model [RFC5812] presents a formal way to define FEs Logical Function Blocks (LFBs) using XML. [RFC5812] was published a little more than two years ago. Current experience in its use has shown some room for adding new and changing existing modeling concepts. This document extends the ForCES Model by a) allowing complex metadata and = b) allowing optional default values for datatypes. These extensions do not = require any changes on the ForCES protocol [RFC5810] as they are simply cha= nges of the schema definition. XML validation is also enhanced. Backward co= mpatibility is ensured, as xml libraries produced with the earlier schema r= emain valid. The abstract could be updated similarly. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4E875eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The abstract and intro say that th= ere are new extensions, but do not give us a clue what they are. Brevity is= good, but it is also helpful to know from the beginning what the remainder of a document contains.

 

Present text (introduction):<= /o:p>

 

The ForCES Model [RFC5812] presents a formal= way to define FEs

Logical Function Blocks (LFBs) using XML. [R= FC5812] has been

published a litlte more than two years and c= urrent experience in its

use has shown some room for adding new and c= hanging existing modeling

concepts.

This document extends the ForCES Model by ch= anging and adding new

concepts. These extensions do not require an= y changes on the ForCES

protocol [RFC5810] as they are simply change= s of the schema

definition. Additionally backward compatibil= ity is ensured as xml

libraries produced with the earlier schema a= re still valid with the

new one.

 

Proposed text:

 

The ForCES Model [RFC5812] presents a formal= way to define FEs

Logical Function Blocks (LFBs) using XML. [R= FC5812] was

published a little more than two years ago. = Current experience in its

use has shown some room for adding new and c= hanging existing modeling

concepts.

This document extends the ForCES Model by a)= allowing complex metadata and b) allowing optional default values for data= types. These extensions do not require any changes on the ForCES protocol [RFC5810] as they are simply changes of= the schema definition. XML validation is also enhanced. Backward compatibi= lity is ensured, as xml libraries produced with the earlier schema remain v= alid.

 

The abstract could be updated simi= larly.

Dave

 

--_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4E875eusaamb105erics_-- From dave.hood@ericsson.com Sun Mar 17 09:22:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2721F8BBC for ; Sun, 17 Mar 2013 09:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPyGKjBBNfHv for ; Sun, 17 Mar 2013 09:22:20 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 677C721F8BD7 for ; Sun, 17 Mar 2013 09:22:20 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-7c-5145edbbb456 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A4.BB.02430.BBDE5415; Sun, 17 Mar 2013 17:22:20 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Sun, 17 Mar 2013 12:22:18 -0400 From: Dave Hood To: "forces@ietf.org" Thread-Topic: Comments: draft-haleplidis-forces-packet-parallelization-01 Thread-Index: Ac4jKtgvQjzRSwZSThmMfpjsEo0VuA== Date: Sun, 17 Mar 2013 16:22:17 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyuXRPuO6et66BBitfcFk8fDObzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGWeetDMW/LSp+DXlKHsD43uzLkZODgkBE4nFi38wQ9hiEhfu rWfrYuTiEBI4wigx88B/KGc5o8Tl7lYmkCo2AQ2JJ5cmg9kiAuoSq29uYwOxhQVcJI4e3cgG EfeUeHzzCyOErSexpLGfHcRmEVCVaJu0C6yXV8BX4sGGnWCbGYE2fz+1BizOLCAucevJfCaI iwQkluw5D3WdqMTLx/9YIWxliSVP9rNA1OdLTPj+nBlipqDEyZlPWCYwCs1CMmoWkrJZSMog 4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I4NNjMDQPybBpruDcc9Ly0OM 0hwsSuK8Qa4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwhuXLmeirp9QWLnvFfrPMqTxZ 3XK/zv3fp46p90hw8Pr3J74p+O9c5PZ4dddWI3eNiHNTN8/VuXjyg/7c5Tf17ctCvszboOer GbqHY+Ju9zezv1xT9wkTy7r/lvlci6Hw0aWtDbcUz0srTn5y+o56zp3gdb82X7tnWTnVSGt1 Jde99SpPVZSNlFiKMxINtZiLihMBr4Sh8UsCAAA= Subject: [forces] Comments: draft-haleplidis-forces-packet-parallelization-01 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, 17 Mar 2013 16:22:21 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The use case for chunk processing is not obvious, and the references sectio= n does not obviously cite a place where such a use case might be described.= An example would be helpful. Some documentation of cilc (is that correct?) should also appear in the ref= erences. In ParallelLFBType AllowedParallelAfters List of LFB Classes that this parallel LFB class can follow in a parallel pipeline AllowedParallelBefores List of LFB Classes that this LFB class can follow in a parallel pipeline Presumably the first synopsis should read precede, rather than follow? Tunneling metadata in case of nested parallelization: this would presumably= require the complex metadata proposed in draft-haleplidis-forces-model-ext= ension-01? ... which therefore should also be cited in the text and listed = in the references. Would a tunneledMetadata typedef be needed? Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The use case for chunk processing = is not obvious, and the references section does not obviously cite a place = where such a use case might be described. An example would be helpful.

 

Some documentation of cilc (is tha= t correct?) should also appear in the references. 

 

In ParallelLFBType

<snip />

<component componentID= =3D"5">

<name>AllowedParallel= Afters</name>

<synopsis>List of LFB= Classes that this parallel LFB

class can follow in a paral= lel pipeline</synopsis>

<snip />

<component componentID= =3D"6">

<name>AllowedParallel= Befores</name>

<synopsis>List of LFB= Classes that this LFB class can

follow in a parallel pipeli= ne</synopsis>

<snip />

Presumably the first synopsis shou= ld read precede, rather than follow?

 

Tunneling metadata in case of nest= ed parallelization: this would presumably require the complex metadata prop= osed in draft-haleplidis-forces-model-extension-01? … which therefore = should also be cited in the text and listed in the references. Would a tunn= eledMetadata typedef be needed? 

 

Dave

 

--_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3eusaamb105erics_-- From dave.hood@ericsson.com Sun Mar 17 09:38:06 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4C021F8678 for ; Sun, 17 Mar 2013 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpC5qMlltrQo for ; Sun, 17 Mar 2013 09:38:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5F96221F857B for ; Sun, 17 Mar 2013 09:38:05 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-d6-5145f16c0545 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 60.D0.02411.C61F5415; Sun, 17 Mar 2013 17:38:04 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Sun, 17 Mar 2013 12:38:03 -0400 From: Dave Hood To: "forces@ietf.org" Thread-Topic: =?utf-8?B?Q29tbWVudHMsIHF1ZXN0aW9uczogZHJhZnTiiJJqb2FjaGltcGlsbGFp4oiS?= =?utf-8?B?Zm9yY2Vz4oiSaW50ZXJmZWxmYuKIkjAx?= Thread-Index: Ac4jLY0Tw9/T/guAS+2+LsppFKHK+w== Date: Sun, 17 Mar 2013 16:38:03 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyuXRPrG7OR9dAgynbjSwevpnN5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNdHNrAXrLCqePz9NGMD4xWLLkZODgkBE4mvJ1cwQ9hiEhfu rWfrYuTiEBI4wijRsnM2K4SznFHia9sidpAqNgENiSeXJjOB2CIC6hKrb24D6xAWaGCU+DDt IROIIyLQyiix9NVvNogqPYmlWzaygNgsAqoSR/5vBJvEK+ArMXfaVbDdjEC7v59aAzaVWUBc 4taT+UwQNwlILNlzHuo+UYmXj/+xQtjKEkue7GeBqM+XmPZ8ISPETEGJkzOfsExgFJqFZNQs JGWzkJTNYuQAimtKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMHKXFqWW56UaGmxiBwX9M gs1xB+OCT5aHGKU5WJTEeUNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJQ6sXyl7tJc Jb3j7xL/H+kr+DZbIYvLuOrx+fy5p43DDIzSNJm1uNQ/6bDMMTkw4/MEk9Pq/HzqNazC58L4 k/138njuvNEsF+Y0IeJc9455amyX587g2SOkNUMh9NezqA0vbsWozKv7LLxuhdzurVVrns29 yX6P57jh7pZHL35Wr+CfrCq/PF2JpTgj0VCLuag4EQA7+6NPTAIAAA== Subject: [forces] =?utf-8?q?Comments=2C_questions=3A_draft=E2=88=92joachim?= =?utf-8?b?cGlsbGFp4oiSZm9yY2Vz4oiSaW50ZXJmZWxmYuKIkjAx?= 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, 17 Mar 2013 16:38:06 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11eusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGludGVyLUFTSUMgcGxveSBpcyBhIHByZXR0eSBibGF0YW50IHdvcmthcm91bmQgZm9yIHRo ZSBzaW5nbGUtYm94IHJlc3RyaWN0aW9uLiBJcyB0aGF0IHJlZ2FyZGVkIGFzIGtvc2hlcj8gT25j ZSB3ZSBuZWVkIHRvIGNyb3NzIGEgcGh5c2ljYWwgYm91bmRhcnksIGJlIGl0IGJldHdlZW4gY2hp cHMsIGJsYWRlcywgYm94ZXMgb3IgbmV0d29ya3MsIHN1cmVseSB3ZSBvdWdodCB0byBiZSB1cC1m cm9udCBhYm91dCBpdCBhbmQgYWRtaXQgd2hhdCB3ZeKAmXJlIGRvaW5nLg0KDQpJdCBpcyBub3Qg Y2xlYXIgZnJvbSB0aGUgZHJhZnQgd2hldGhlciBlYWNoIExGQiBsaW5rIGJldHdlZW4gdHdvIGRl dmljZXMgd291bGQgaGF2ZSBpdHMgb3duIGluc3RhbmNlIHBhaXIgb2YgaW50ZXItRkVMQnMsIG9y IHdoZXRoZXIgdGhlIGlkZW50aWZpZXJzIGFyZSBpbnRlbmRlZCB0byBhY3QgYXMgbXVsdGlwbGV4 IHRhZ3MsIHN1Y2ggdGhhdCBhbnkgbnVtYmVyIG9mIFtsaWtlP10gTEZCcyBvbiB0aGUgc2FtZSB0 d28gZGV2aWNlcyBjb3VsZCBzaGFyZSBhbiBpbnRlcmZhY2UuIEkgcHJlc3VtZSB0aGUgbGF0dGVy LCBvciBwZXJoYXBzIHRoZSBsYXR0ZXIgYnV0IHdpdGggY2xhcmlmaWNhdGlvbnMgb3IgcmVzdHJp Y3Rpb25zLCBidXQgYSBkZWZpbml0ZSBzdGF0ZW1lbnQgd291bGQgYmUgaGVscGZ1bC4NCg0KV2hl biB3ZSBzdGFydCB0YWxraW5nIGFib3V0IG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIHdlIGNvdWxk IGVuZCB1cCB3aXRoIHNldmVyYWwgbGF5ZXJzIFt3aG9sZXNhbGUgY2FzZSwgcHJvdmlkZXJz4oCZ IHByb3ZpZGVyXSBvZiBlbmNhcHN1bGF0ZWQgbWV0YWRhdGEgY3Jvc3Npbmcgd2lkZSBnZW9ncmFw aGljIGFyZWFzIGFtb25nc3QgYSBudW1iZXIgb2YgYm94ZXMuIE1heWJlIHRoZSB2aXJ0dWFsIG5l dHdvcmsgcGxhbm5lciB3aWxsIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgdG9wb2xvZ3ktbWV0YWRh dGEgcmVsYXRpb25zaGlwcyB0byBlbnN1cmUgdGhhdCBsaXR0bGUgdG8gbm8gbWV0YWRhdGEgaXMg cmVxdWlyZWQ/IEV2ZW4gc28sIHRoaXMgZHJhZnQgZG9lcyBub3QgYWxsb3cgZm9yIG51bGwgbWV0 YWRhdGEuIEhhcyBhbGwgb2YgdGhhdCBhbHJlYWR5IGJlZW4gcmVjb2duaXplZCBhbmQgZGlzY3Vz c2VkPyBPciBpZiB0aGlzIGlzIG91dCBvZiBzY29wZSwgaG93IHdvdWxkIHdlIGVuc3VyZSB0aGF0 IGl0IHJlbWFpbnMgb3V0IG9mIHNjb3BlPw0KDQpEYXZlDQo= --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11eusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1pY3Jvc29mdCBZaSBCYWl0aSI7DQoJcGFub3NlLTE6MyAwIDUgMCAwIDAgMCAwIDAgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUi Ow0KCXBhbm9zZS0xOjIgNSA2IDQgNSA1IDUgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9y OndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VGhlIGludGVyLUFTSUMgcGxveSBpcyBhIHByZXR0eSBibGF0YW50IHdvcmthcm91bmQg Zm9yIHRoZSBzaW5nbGUtYm94IHJlc3RyaWN0aW9uLiBJcyB0aGF0IHJlZ2FyZGVkIGFzIGtvc2hl cj8mbmJzcDtPbmNlIHdlIG5lZWQgdG8gY3Jvc3MgYSBwaHlzaWNhbCBib3VuZGFyeSwgYmUgaXQg YmV0d2Vlbg0KIGNoaXBzLCBibGFkZXMsIGJveGVzIG9yIG5ldHdvcmtzLCBzdXJlbHkgd2Ugb3Vn aHQgdG8gYmUgdXAtZnJvbnQgYWJvdXQgaXQgYW5kIGFkbWl0IHdoYXQgd2XigJlyZSBkb2luZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkl0IGlzIG5v dCBjbGVhciBmcm9tIHRoZSBkcmFmdCB3aGV0aGVyIGVhY2ggTEZCIGxpbmsgYmV0d2VlbiB0d28g ZGV2aWNlcyB3b3VsZCBoYXZlIGl0cyBvd24gaW5zdGFuY2UgcGFpciBvZiBpbnRlci1GRUxCcywg b3Igd2hldGhlciB0aGUgaWRlbnRpZmllcnMgYXJlIGludGVuZGVkIHRvDQogYWN0IGFzIG11bHRp cGxleCB0YWdzLCBzdWNoIHRoYXQgYW55IG51bWJlciBvZiBbbGlrZT9dIExGQnMgb24gdGhlIHNh bWUgdHdvIGRldmljZXMgY291bGQgc2hhcmUgYW4gaW50ZXJmYWNlLiBJIHByZXN1bWUgdGhlIGxh dHRlciwgb3IgcGVyaGFwcyB0aGUgbGF0dGVyIGJ1dCB3aXRoIGNsYXJpZmljYXRpb25zIG9yIHJl c3RyaWN0aW9ucywgYnV0IGEgZGVmaW5pdGUgc3RhdGVtZW50IHdvdWxkIGJlIGhlbHBmdWwuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XaGVu IHdlIHN0YXJ0IHRhbGtpbmcgYWJvdXQgbmV0d29yayB2aXJ0dWFsaXphdGlvbiwgd2UgY291bGQg ZW5kIHVwIHdpdGggc2V2ZXJhbCBsYXllcnMgW3dob2xlc2FsZSBjYXNlLCBwcm92aWRlcnPigJkg cHJvdmlkZXJdIG9mIGVuY2Fwc3VsYXRlZCBtZXRhZGF0YSBjcm9zc2luZyB3aWRlDQogZ2VvZ3Jh cGhpYyBhcmVhcyBhbW9uZ3N0IGEgbnVtYmVyIG9mIGJveGVzLiBNYXliZSB0aGUgdmlydHVhbCBu ZXR3b3JrIHBsYW5uZXIgd2lsbCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIHRvcG9sb2d5LW1ldGFk YXRhIHJlbGF0aW9uc2hpcHMgdG8gZW5zdXJlIHRoYXQgbGl0dGxlIHRvIG5vIG1ldGFkYXRhIGlz IHJlcXVpcmVkPyBFdmVuIHNvLCB0aGlzIGRyYWZ0IGRvZXMgbm90IGFsbG93IGZvciBudWxsIG1l dGFkYXRhLiBIYXMgYWxsIG9mIHRoYXQNCiBhbHJlYWR5IGJlZW4gcmVjb2duaXplZCBhbmQgZGlz Y3Vzc2VkPyZuYnNwO09yIGlmIHRoaXMgaXMgb3V0IG9mIHNjb3BlLCBob3cgd291bGQgd2UgZW5z dXJlIHRoYXQgaXQgcmVtYWlucyBvdXQgb2Ygc2NvcGU/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxl JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11eusaamb105erics_-- From hadi@mojatatu.com Mon Mar 18 03:48:27 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DBC21F8976 for ; Mon, 18 Mar 2013 03:48:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoXjfGvhOaIu for ; Mon, 18 Mar 2013 03:48:27 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 14CFF21F8922 for ; Mon, 18 Mar 2013 03:48:26 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ht11so2829216vcb.27 for ; Mon, 18 Mar 2013 03:48:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=QZH4iwC8EXfNXKVHTF2wW2+/kEtfPTfiq3GsRgxqHTI=; b=l4+zWUqDdJz5TLsdc5HWTJGRiVmqtR4hIkj2J/tc8eoWTczJdpzXD5Zh+yctBcfSqg bVSXyqFc8KqN4kGLpjk6A4jzXSyu5BeTf9SGdd835e2Cm/4dv5qHTzvpyTWTJNl9Zb2z X3eqqrL87GNPqTn6GhH234Db/KaVCP2HdX5L1rKuhzOeLjtdB8yT2hCDQyMfrWg0dQVJ LMZ1bRp00jjOxV9qcXCMNqkaBfA893VqAVmOo0OIzuJYHd34ywRuXiJP4GMS+HSNpV8O f7u6xyeYrKn2UeZIrMZB1BO42fN21xFeHdd/Y96xnfkFoTJeE1uMyK8SKYptMXR/dM4I Hhow== X-Received: by 10.52.20.177 with SMTP id o17mr16846198vde.17.1363603706502; Mon, 18 Mar 2013 03:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.137 with HTTP; Mon, 18 Mar 2013 03:48:06 -0700 (PDT) In-Reply-To: <000f01ce2315$a6d5d500$f4817f00$@com> References: <000f01ce2315$a6d5d500$f4817f00$@com> From: Jamal Hadi Salim Date: Mon, 18 Mar 2013 06:48:06 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn/4dmCdQzCQOn/mX3mg/0N5jP1l502WJ9VWvft8X0pLrJ0gY1QYkFYgtI6Ou3Mz2cAtGaX Cc: forces@ietf.org Subject: Re: [forces] Recharter 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, 18 Mar 2013 10:48:28 -0000 Greetings Evangelos, On Sun, Mar 17, 2013 at 9:45 AM, Haleplidis Evangelos wrote: > Greetings to the list, > > Just a few minor comments: > > 1. For the model extension please add: > "5. Define new events to monitor states" > This is for having in mind to add "Becomes Equal To" and probably "Becomes > Not Equal To". > > 1. Change a bit the wording in: > "The protocol extension will" > To > "The protocol extensions will" > > And in the numbers under change the wording to probably" > "1. Define a table range query" > "2. Define a table append" > "3. Define additional..." > > 3. For the protocol extension also please add: > "4. Define data packing rule for bitmap datatype". > Although a suggestion is defined in the model, this detail should reside in > the protocol document. Done for both items. > 4. The Inter-FE Connectivity is written twice - delete one. I think this was a cutnpaste error from local copy to email client; on the file residing on my disk it looks fine. cheers, jamal > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >> Behalf Of Jamal Hadi Salim >> Sent: Wednesday, March 13, 2013 12:16 PM >> To: forces@ietf.org >> Subject: [forces] Recharter >> >> Folks, >> >> We have a recharter! >> Thanks to Adrian and everyone in the WG who worked hard to get us here. >> The strawman charter was posted yesterday, the wording is highly likely >> to change. >> Please provide comments on the wording etc. >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Mon Mar 18 05:08:35 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BEA21F8D29 for ; Mon, 18 Mar 2013 05:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGx4HhYyltSW for ; Mon, 18 Mar 2013 05:08:34 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 622E221F8D26 for ; Mon, 18 Mar 2013 05:08:34 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id b13so3310614vby.33 for ; Mon, 18 Mar 2013 05:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XF8VQfB1hF47lbBWLI+gTHTFU+wNBDnplmYF47Cs9eA=; b=drO+uXtwKQ5DLStlVqLC8yhApNIozL3PK3rb/fgBcyRxsadTmdJiS5B/OrR2Eujzws BTafuVdsDIuY6NspTkGbyBkeWncALT9hy5EmpONYXw5WaYd3WKDdi1CD/8HkPcvrWpyA 1Hbu2N35xw8y5uNH/GDrhfw2ZiUBd72NhPyvF1vllGt8fvbgJLRfO2jWFjnOa/jzt5/m UMFDEQ/VA6FKukc6yfLlu7PE0yF1ltTp3eFvU4D/C74q4C/Y6Qiq6a7Zs72Hb20CIcVR XVAZOog+I/WCvl7Rc/DAi2JEfJI6md2eT75clQBzdLC8yrFKfg+VecFma5+ajkS3jTpF ibhw== X-Received: by 10.52.36.234 with SMTP id t10mr16703447vdj.95.1363608513515; Mon, 18 Mar 2013 05:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.137 with HTTP; Mon, 18 Mar 2013 05:08:13 -0700 (PDT) In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> From: Jamal Hadi Salim Date: Mon, 18 Mar 2013 08:08:13 -0400 Message-ID: To: Dave Hood Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmwlPSlrAgDMTXcqZm3zfrHftFBRtxWoJsy5RLyndk/4ZjsZcXbHmFrAlB+D9K2cJHoV7qJ Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 18 Mar 2013 12:08:35 -0000 Dave, Your input is appreciated. On Sun, Mar 17, 2013 at 12:38 PM, Dave Hood wrote: > The inter-ASIC ploy is a pretty blatant workaround for the single-box > restriction. Is that regarded as kosher? > Once we need to cross a physical > boundary, be it between chips, blades, boxes or networks, surely we ought= to > be up-front about it and admit what we=92re doing. > Did you mean the text around figure2? Didnt grok the context. We were hoping to support existing infrastructure with the transport mapping (eg a marvel chip being able to transpose the metadata across two chips/boards where sensible). > It is not clear from the draft whether each LFB link between two devices > would have its own instance pair of inter-FELBs, or whether the identifie= rs > are intended to act as multiplex tags, such that any number of [like?] LF= Bs > on the same two devices could share an interface. I presume the latter, o= r > perhaps the latter but with clarifications or restrictions, but a definit= e > statement would be helpful. Agreed we need more illustrative text. In current prototyping we use a pair of the inter-FE LFBs per FE and it see= ms sufficient. To be more general, however, the CE should have the luxury of instantiating more than one pair when needed. Example, it may be sensible and probably more efficient (implementation dependent) in creating one pair per tenant. > When we start talking about network virtualization, we could end up with > several layers [wholesale case, providers=92 provider] of encapsulated > metadata crossing wide geographic areas amongst a number of boxes. I am not familiar with the space you describe - is the anology equivalent to say several encapsulated 8021q tags? > Maybe the > virtual network planner will need to understand the topology-metadata > relationships to ensure that little to no metadata is required? Not sure if i am answering the question: The metadata is supposed to be described on a per-LFB basis, will be documented on each LFB description document, created when needed by the datapath and is to be consumed by downstream LFBs that understand and expect it (per those LFB-specific documents). The draft suggests that the CE will tell the inter-FE LFB of white or black lists of metadata to pass through. >Even so, > this draft does not allow for null metadata. Metadata is optional as is packet data (i.e one could send across only meta= data) >Has all of that already been > recognized and discussed? Or if this is out of scope, how would we ensure > that it remains out of scope? > It is within scope. The current ForCES architecture allows either the FE or CE to send optional packetdata + metadata (refer to: https://tools.ietf.org/html/rfc5810#section-7.9 ) In the draft we used/assumed that experience. Do we need more descriptive text? cheers, jamal > > > Dave > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From damascene.joachimpillai@verizon.com Mon Mar 18 08:14:52 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1CB21F8C8F for ; Mon, 18 Mar 2013 08:14: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BYjf8vWSkp8 for ; Mon, 18 Mar 2013 08:14:52 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E521F8D24 for ; Mon, 18 Mar 2013 08:14:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 18 Mar 2013 15:13:20 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="433006535" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 18 Mar 2013 15:12:16 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Mon, 18 Mar 2013 11:12:16 -0400 To: 'Jamal Hadi Salim' , Dave Hood Date: Mon, 18 Mar 2013 11:12:15 -0400 Thread-Topic: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 Thread-Index: Ac4j0VX+8SmLeyl4Se++h0yOOW5+0wAGV4vA Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 18 Mar 2013 15:14:52 -0000 Jamal, It may beg the question what constitutes a LFB and what constitutes an FE.= =20 Is TCAM a LFB or an FE?=20 I have been using a very loose definition in our implementation.=20 Regards, DJ -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Jamal Hadi Salim Sent: Monday, March 18, 2013 8:08 AM To: Dave Hood Cc: forces@ietf.org Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-inter= felfb-01 Dave, Your input is appreciated. On Sun, Mar 17, 2013 at 12:38 PM, Dave Hood wrote: > The inter-ASIC ploy is a pretty blatant workaround for the single-box=20 > restriction. Is that regarded as kosher? > Once we need to cross a physical > boundary, be it between chips, blades, boxes or networks, surely we=20 > ought to be up-front about it and admit what we're doing. > Did you mean the text around figure2? Didnt grok the context. We were hoping to support existing infrastructure with the transport mappin= g (eg a marvel chip being able to transpose the metadata across two chips/b= oards where sensible). > It is not clear from the draft whether each LFB link between two=20 > devices would have its own instance pair of inter-FELBs, or whether=20 > the identifiers are intended to act as multiplex tags, such that any=20 > number of [like?] LFBs on the same two devices could share an=20 > interface. I presume the latter, or perhaps the latter but with=20 > clarifications or restrictions, but a definite statement would be helpful= . Agreed we need more illustrative text. In current prototyping we use a pair of the inter-FE LFBs per FE and it see= ms sufficient. To be more general, however, the CE should have the luxury of instantiating= more than one pair when needed. Example, it may be sensible and probably m= ore efficient (implementation dependent) in creating one pair per tenant. > When we start talking about network virtualization, we could end up=20 > with several layers [wholesale case, providers' provider] of=20 > encapsulated metadata crossing wide geographic areas amongst a number of = boxes. I am not familiar with the space you describe - is the anology equivalent t= o say several encapsulated 8021q tags? > Maybe the > virtual network planner will need to understand the topology-metadata=20 > relationships to ensure that little to no metadata is required? Not sure if i am answering the question: The metadata is supposed to be described on a per-LFB basis, will be docume= nted on each LFB description document, created when needed by the datapath = and is to be consumed by downstream LFBs that understand and expect it (per= those LFB-specific documents). The draft suggests that the CE will tell the inter-FE LFB of white or black= lists of metadata to pass through. >Even so, > this draft does not allow for null metadata. Metadata is optional as is packet data (i.e one could send across only meta= data) >Has all of that already been > recognized and discussed? Or if this is out of scope, how would we=20 >ensure that it remains out of scope? > It is within scope. The current ForCES architecture allows either the FE or CE to send optional= packetdata + metadata (refer to: https://tools.ietf.org/html/rfc5810#section-7.9 ) In the draft we used/assu= med that experience. Do we need more descriptive text? cheers, jamal > > > Dave > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From joel@stevecrocker.com Mon Mar 18 08:18:54 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789E121F8CCB for ; Mon, 18 Mar 2013 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEvUrbgcemDw for ; Mon, 18 Mar 2013 08:18:53 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4C821F85C9 for ; Mon, 18 Mar 2013 08:18:53 -0700 (PDT) Received: from dummy.name; Mon, 18 Mar 2013 15:18:52 +0000 Message-ID: <5147305A.1080205@stevecrocker.com> Date: Mon, 18 Mar 2013 11:18:50 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Joachimpillai, Damascene M" References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 18 Mar 2013 15:18:54 -0000 The point I drew from Dave's message was a differet one. hat we want to accomplish is to allow metadata to be passed between FEs, typically across Ethernet. We should say that up front, and not try to justify it on the basis of specific hardware architecture (te scope of ASICs.) The definition of an FE is effectively "the set of things under the control of a single client." Conceptually, it is up to the FE itself how it passes metadata among its parts. Where we get to talk about real bits on (real or virtual) wires is where things go in and out of an FE. Yours, Joel On 3/18/2013 11:12 AM, Joachimpillai, Damascene M wrote: > Jamal, > > It may beg the question what constitutes a LFB and what constitutes an FE. > Is TCAM a LFB or an FE? > > I have been using a very loose definition in our implementation. > > Regards, > DJ > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi Salim > Sent: Monday, March 18, 2013 8:08 AM > To: Dave Hood > Cc: forces@ietf.org > Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 > > Dave, > > Your input is appreciated. > > On Sun, Mar 17, 2013 at 12:38 PM, Dave Hood wrote: >> The inter-ASIC ploy is a pretty blatant workaround for the single-box >> restriction. Is that regarded as kosher? >> Once we need to cross a physical >> boundary, be it between chips, blades, boxes or networks, surely we >> ought to be up-front about it and admit what we're doing. >> > > Did you mean the text around figure2? Didnt grok the context. > We were hoping to support existing infrastructure with the transport mapping (eg a marvel chip being able to transpose the metadata across two chips/boards where sensible). > >> It is not clear from the draft whether each LFB link between two >> devices would have its own instance pair of inter-FELBs, or whether >> the identifiers are intended to act as multiplex tags, such that any >> number of [like?] LFBs on the same two devices could share an >> interface. I presume the latter, or perhaps the latter but with >> clarifications or restrictions, but a definite statement would be helpful. > > Agreed we need more illustrative text. > In current prototyping we use a pair of the inter-FE LFBs per FE and it seems sufficient. > To be more general, however, the CE should have the luxury of instantiating more than one pair when needed. Example, it may be sensible and probably more efficient (implementation dependent) in creating one pair per tenant. > >> When we start talking about network virtualization, we could end up >> with several layers [wholesale case, providers' provider] of >> encapsulated metadata crossing wide geographic areas amongst a number of boxes. > > I am not familiar with the space you describe - is the anology equivalent to say several encapsulated 8021q tags? > >> Maybe the >> virtual network planner will need to understand the topology-metadata >> relationships to ensure that little to no metadata is required? > > Not sure if i am answering the question: > The metadata is supposed to be described on a per-LFB basis, will be documented on each LFB description document, created when needed by the datapath and is to be consumed by downstream LFBs that understand and expect it (per those LFB-specific documents). > > The draft suggests that the CE will tell the inter-FE LFB of white or black lists of metadata to pass through. > >> Even so, >> this draft does not allow for null metadata. > > Metadata is optional as is packet data (i.e one could send across only metadata) > >> Has all of that already been >> recognized and discussed? Or if this is out of scope, how would we >> ensure that it remains out of scope? >> > > It is within scope. > The current ForCES architecture allows either the FE or CE to send optional packetdata + metadata (refer to: > https://tools.ietf.org/html/rfc5810#section-7.9 ) In the draft we used/assumed that experience. Do we need more descriptive text? > > cheers, > jamal > >> >> >> Dave >> >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Wed Mar 20 04:45:05 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5F21F84A9 for ; Wed, 20 Mar 2013 04:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBrOGcfTNMGX for ; Wed, 20 Mar 2013 04:45:05 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D621F85CE for ; Wed, 20 Mar 2013 04:45:04 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id w11so785861bku.8 for ; Wed, 20 Mar 2013 04:44:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Rdh+XfGWT02XIpcZFKWD+AH1/4/iE16aCJ7KRcCqBpE=; b=pShX17bteuNak7xfWDnBAjQFTLc7TNrVLAcDGMn2socjpl0oeuKxs6Via/S3g/FuQa zHV+55WYjbDJjW7wPfGjIgVwOaxe2mV03VqrlOhd/FuxkowrcLf9H1RWXAaLKBRrbz1i YvxrCHorOLr8H9gstk+iAuubTJ/FgtoeWCxWxaiS1Qa204hR3l6uPllfjakmTMowKV9b PiItkCvgqBLNQiljfx2Pf1jOZZhoAM2Ci+pXhTQKP5VRzqJoAjoSC1yba828LAwIx2/w EiPjKOsggOSrpRTwrN+gHw7cXQkOMu3LqfbMp5CO+C1G7eyyL0RM+h9hD5ocf4b/fzQW ywKA== X-Received: by 10.205.127.11 with SMTP id gy11mr10681336bkc.54.1363779895922; Wed, 20 Mar 2013 04:44:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.145.77 with HTTP; Wed, 20 Mar 2013 04:44:35 -0700 (PDT) In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> From: Jamal Hadi Salim Date: Wed, 20 Mar 2013 07:44:35 -0400 Message-ID: To: "Joachimpillai, Damascene M" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnGVJJ0rR2J99z/TCb1RGFkgN93R5yNol5aGGcuJRqm9broo80QxQ4NVIPziL4ZV6kw45zn Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 20 Mar 2013 11:45:06 -0000 Hi DJ, Sorry - very distracted elsewhere the last 2 days. On Mon, Mar 18, 2013 at 11:12 AM, Joachimpillai, Damascene M wrote: > Jamal, > > It may beg the question what constitutes a LFB and what constitutes an FE. > Is TCAM a LFB or an FE? > I think it could be modelled as an LFB Class. And if you have multiple of them, there would be multiple instances. Of course such an LFB class could be in its own FE. cheers, jamal From hadi@mojatatu.com Wed Mar 20 05:03:14 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9D21F87D3 for ; Wed, 20 Mar 2013 05:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.358 X-Spam-Level: X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqKZRAyfCUlC for ; Wed, 20 Mar 2013 05:03:13 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6762221F8735 for ; Wed, 20 Mar 2013 05:03:13 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jc3so782634bkc.6 for ; Wed, 20 Mar 2013 05:03:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=tykJOn7bDL3Qtd5MPicgRj+mY0OwgZUoVmnnb/N7w2w=; b=cJgbGwn8fy3lkKf7HcY+zYvNsn4VqzjZd0xX7TzlXc8G8Gt4bKHGUp5bFRSomdD5SX z115a4t+eBjiGkRxF8Isy2V3zdQkwRG8Nx3mX+RL68p4srkDYObBTiqEAclaj2qkljTv 2RrTegBWcsvnh/ag6wLNOAQgjTQ3WKjmsJg0wz9VGaekdJRHqA4dcK3xm5hC00xL9o4j WuIrN57dK+zIdInN2zr3+6vIpJ6UG9a5Tg+tFNbuf/d+C8Ur3VJnYlO1PCVGpwpR6pvx eelbbUFbW7jiYzP8a9zXG/rgiTgS3eWLMzUkjafXPABWMX7HvEWKq6n8rEGfxornOGTt Xj6Q== X-Received: by 10.205.40.202 with SMTP id tr10mr10708668bkb.24.1363780992333; Wed, 20 Mar 2013 05:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.145.77 with HTTP; Wed, 20 Mar 2013 05:02:52 -0700 (PDT) In-Reply-To: <5147305A.1080205@stevecrocker.com> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> <5147305A.1080205@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 20 Mar 2013 08:02:52 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk1PgWdHKu9/7vltHZfNtGv9pGlPL21Mk26UDOHr3XCh7Kzx7NFoPahvW5LPkj3vOnt9Bdb Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 20 Mar 2013 12:03:14 -0000 On Mon, Mar 18, 2013 at 11:18 AM, Joel wrote: > The point I drew from Dave's message was a differet one. > what we want to accomplish is to allow metadata to be passed > between FEs, > typically across Ethernet. We should say that up front, and not try to > justify it on the basis of specific hardware architecture (te scope of > ASICs.) > What you described is precisely the short term goal we want to achieve. But i dont think we can ignore other FE interconnects in a general standard, can we? If i have several broadcom chips interconnected via higig then it is important to be able to model that so i can control and configure attributes from the CE (when it makes sense to do so). Is the suggestion we just focus on ethernet only for simplicity of a first cut? On my part, at least, I think that ability to go across some IP infrastructure (when FEs are VMs across networks) is important. > The definition of an FE is effectively "the set of things under > the control > of a single client." Conceptually, it is up to the FE itself how it passes > metadata among its parts. Where we get to talk about real bits on > (real or virtual) wires is where things go in and out of an FE. > Agreed. To my point above: Going across hi-gig is things going in/out of FEs cheers, jamal From hadi@mojatatu.com Wed Mar 20 05:14:48 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3D21F84BC for ; Wed, 20 Mar 2013 05:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.771 X-Spam-Level: X-Spam-Status: No, score=-101.771 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcXATmy3w3oM for ; Wed, 20 Mar 2013 05:14:47 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6061121F8491 for ; Wed, 20 Mar 2013 05:14:47 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id jg9so795634bkc.9 for ; Wed, 20 Mar 2013 05:14:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=z7h9IHXJWeytNuMV/xrEqFffiZc7e+1obprvw1kqNrI=; b=fgix3MzhOQOwgNEnChAJvoNn/LH50SEqfFAaoqEhNEnrOIo9shdg9eyIhDDZlc/OLu TlbDTdYncBPnNjOqohCp+y3vRCi5U0llC/CPskWUGqQyNZ+5TkZEz9x4NG/BDQUPvFdk amizGkd8Rjq81yw3wYym7fSIja4ti+JQi/tRSKUw63eoJXQgFo4sPEKob9hUFE8iQMNZ lLufvqq4NAvKus45NolA98W3e0MQzz699vlyxG6rmhdCK3QNo4VkUmfjIxVAqfjCYrDq eqo01OwMmmt1qrlqdeLkmwqdEcOdXUs1P+8er9pWg2Fek75Czd3EfrJ+spk9oiR29cKr 9KZQ== X-Received: by 10.205.138.148 with SMTP id is20mr10961828bkc.45.1363781686329; Wed, 20 Mar 2013 05:14:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.145.77 with HTTP; Wed, 20 Mar 2013 05:14:26 -0700 (PDT) In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> From: Jamal Hadi Salim Date: Wed, 20 Mar 2013 08:14:26 -0400 Message-ID: To: "Joachimpillai, Damascene M" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnWo8cZVcNVe7EmuBH2m+q8M2/TmZV92EI05kbI/pu2cXTh5LbXcIOwD1avge5ZXMTSCcnf Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 20 Mar 2013 12:14:48 -0000 Hrm. This was sitting on my outbox for some reason; if you see duplicates ignore one. Hi DJ, Sorry - very distracted elsewhere the last 2 days. On Mon, Mar 18, 2013 at 11:12 AM, Joachimpillai, Damascene M wrote: > Jamal, > > It may beg the question what constitutes a LFB and what constitutes an FE. > Is TCAM a LFB or an FE? > I think it could be modelled as an LFB Class. And if you have multiple of them, there would be multiple instances. Of course such an LFB class could be in its own FE. cheers, jamal From dave.hood@ericsson.com Wed Mar 20 08:27:23 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D4121F8FDC for ; Wed, 20 Mar 2013 08:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc3Zb-4106C2 for ; Wed, 20 Mar 2013 08:27:15 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 306D111E80D3 for ; Wed, 20 Mar 2013 08:27:11 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-ff-5149d543a894 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E9.4B.02411.345D9415; Wed, 20 Mar 2013 16:27:00 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 11:26:59 -0400 From: Dave Hood To: Jamal Hadi Salim , Joel Thread-Topic: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 Thread-Index: AQHOI+vsq3VMkgM2l0Ss/iWBMJTppJiuwOgA///0pYA= Date: Wed, 20 Mar 2013 15:26:59 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA6405F52B68@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> <5147305A.1080205@stevecrocker.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPoK7LVc9Ag/NbWCxOL57BbPHwzWw2 i9tb97BZ7Nr4lcmBxWPJkp9MHtturWX1mH30GJNH63fRAJYoLpuU1JzMstQifbsEroxPX/ey FzwXrPh6cRFjA+M8vi5GTg4JAROJlwv2sULYYhIX7q1nA7GFBI4wStxdwtLFyAVkL2eU+Pt0 JyNIgk1AQ+LJpclMILaIgJvE2W03weLMArkSiw7uAWsWFgiV2LPjEFRNmMS0xe3sXYwcQLaV xNe75iBhFgFVifkN08FaeQV8Jb5Mv8wIsesSk0Tr3AssIAlOgUCJfb+bwI5jBDru+6k1TBC7 xCVuPZnPBHG0gMSSPeeZIWxRiZeP/0E9oyzxfc4jFoh6HYkFuz+xQdjaEssWvmaGWCwocXLm E5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLcxAiMpWMSbI47GBd8sjzEKM3BoiTO G+p6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI+ex2RMP6sbW9ZUsqH25yX+V7fKajbm5 l7+1cV/Ocm3ZH39ozw7XSqWEC5uMuSpuSB8Sjnt34+MkR/ZjM5f4zH+5Ir0zP+XqF4eF/zSW PVJJY7jI+Mcz6XDJUaX1nvtzzuQ+vPg0yMlk/a102+vRLisbvzHecftz9cw3jW1lZeEyOSce MG+1jFFiKc5INNRiLipOBACsax8ZcwIAAA== Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 20 Mar 2013 15:27:45 -0000 When two chips reside on the same board, it may suffice to define metadata = forwarding in an abstract way; the chip designer and the board designer car= e how it happens, but standardization probably does not. When the chips res= ide on separate boards, but in a common backplane, this is arguably still t= rue. When two separate boxes are involved, and if they are expected to be intero= perable, we surely need standard definitions of the metadata and how it is = to be forwarded. Ethernet would be a logical starting point, but not necess= arily the only encapsulation that needs to be defined. Dave -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 Sent: Wednesday, March 20, 2013 5:03 AM To: Joel Cc: Joachimpillai, Damascene M; Dave Hood; forces@ietf.org Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-inter= felfb-01 On Mon, Mar 18, 2013 at 11:18 AM, Joel wrote: > The point I drew from Dave's message was a differet one. > what we want to accomplish is to allow metadata to be passed between=20 > FEs, typically across Ethernet. We should say that up front, and not=20 > try to justify it on the basis of specific hardware architecture (te=20 > scope of > ASICs.) > What you described is precisely the short term goal we want to achieve. But= i dont think we can ignore other FE interconnects in a general standard, c= an we? If i have several broadcom chips interconnected via higig then it is import= ant to be able to model that so i can control and configure attributes from= the CE (when it makes sense to do so). Is the suggestion we just focus on ethernet only for simplicity of a first = cut? On my part, at least, I think that ability to go across some IP infrastruct= ure (when FEs are VMs across networks) is important. > The definition of an FE is effectively "the set of things under the=20 > control of a single client." Conceptually, it is up to the FE itself=20 > how it passes metadata among its parts. Where we get to talk about=20 > real bits on (real or virtual) wires is where things go in and out of=20 > an FE. > Agreed. To my point above: Going across hi-gig is things going in/out of FEs cheers, jamal From joel@stevecrocker.com Wed Mar 20 08:41:14 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE021F8FAB for ; Wed, 20 Mar 2013 08:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_DSL=1.129, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGORDtmNadSr for ; Wed, 20 Mar 2013 08:41:14 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 11A8B21F8FA4 for ; Wed, 20 Mar 2013 08:41:13 -0700 (PDT) Received: from dummy.name; Wed, 20 Mar 2013 15:41:12 +0000 Message-ID: <5149D893.6050801@stevecrocker.com> Date: Wed, 20 Mar 2013 11:41:07 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dave Hood References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> <5147305A.1080205@stevecrocker.com> <8D15A2BAF93E9C49AB037A0647E5FA6405F52B68@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA6405F52B68@eusaamb105.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 20 Mar 2013 15:41:14 -0000 Where it gets more complicated than the picture below is when one looks at backplanes that are ATCA or similar (Ethernet, wit cards from different vendors), or chipmakers wanting to use standard interfaces in and out of their chip (e.g. Ethernet). Having said that, I think it is much clearer if the document focuses on the inter-fe problem with separate boxes as the canonical case. The other cases can be mention as furhter examples where this work may apply. Doing it the other way looks like we are trying to slide a big deal under a hole in the existing limits. Yours, Joel On 3/20/2013 11:26 AM, Dave Hood wrote: > When two chips reside on the same board, it may suffice to define metadata forwarding in an abstract way; the chip designer and the board designer care how it happens, but standardization probably does not. When the chips reside on separate boards, but in a common backplane, this is arguably still true. > > When two separate boxes are involved, and if they are expected to be interoperable, we surely need standard definitions of the metadata and how it is to be forwarded. Ethernet would be a logical starting point, but not necessarily the only encapsulation that needs to be defined. > > Dave > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Wednesday, March 20, 2013 5:03 AM > To: Joel > Cc: Joachimpillai, Damascene M; Dave Hood; forces@ietf.org > Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 > > On Mon, Mar 18, 2013 at 11:18 AM, Joel wrote: >> The point I drew from Dave's message was a differet one. >> what we want to accomplish is to allow metadata to be passed between >> FEs, typically across Ethernet. We should say that up front, and not >> try to justify it on the basis of specific hardware architecture (te >> scope of >> ASICs.) >> > > What you described is precisely the short term goal we want to achieve. But i dont think we can ignore other FE interconnects in a general standard, can we? > If i have several broadcom chips interconnected via higig then it is important to be able to model that so i can control and configure attributes from the CE (when it makes sense to do so). > Is the suggestion we just focus on ethernet only for simplicity of a first cut? > On my part, at least, I think that ability to go across some IP infrastructure (when FEs are VMs across networks) is important. > >> The definition of an FE is effectively "the set of things under the >> control of a single client." Conceptually, it is up to the FE itself >> how it passes metadata among its parts. Where we get to talk about >> real bits on (real or virtual) wires is where things go in and out of >> an FE. >> > > Agreed. > To my point above: Going across hi-gig is things going in/out of FEs > > cheers, > jamal > From adrian@olddog.co.uk Thu Mar 21 09:06:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CCA21F9106 for ; Thu, 21 Mar 2013 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaVAXu-8CXEZ for ; Thu, 21 Mar 2013 09:06:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D6B9821F90EC for ; Thu, 21 Mar 2013 09:06:37 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2LG6Uua004310; Thu, 21 Mar 2013 16:06:31 GMT Received: from 950129200 ([88.128.80.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2LG6RS1004243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 16:06:30 GMT From: "Adrian Farrel" To: "'Jamal Hadi Salim'" References: <000f01ce2315$a6d5d500$f4817f00$@com> In-Reply-To: Date: Thu, 21 Mar 2013 16:06:26 -0000 Message-ID: <038301ce264e$0dce1fc0$296a5f40$@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: AQHuRUsiYDtzpg+ZgpDTvz0dEAg87gHnjEKmAdeM1UqYUfEYgA== Content-Language: en-gb Cc: forces@ietf.org Subject: Re: [forces] Recharter X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:06:38 -0000 Hi Jamal, Can you mail me the latest. I will put it into the data tracker and then we can track edit. (Yes, my review is still pending, but it is comforting to not hear any screams from the WG). A > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of > Jamal Hadi Salim > Sent: 18 March 2013 10:48 > To: Haleplidis Evangelos > Cc: forces@ietf.org > Subject: Re: [forces] Recharter > > Greetings Evangelos, > > On Sun, Mar 17, 2013 at 9:45 AM, Haleplidis Evangelos > wrote: > > Greetings to the list, > > > > Just a few minor comments: > > > > 1. For the model extension please add: > > "5. Define new events to monitor states" > > This is for having in mind to add "Becomes Equal To" and probably "Becomes > > Not Equal To". > > > > 1. Change a bit the wording in: > > "The protocol extension will" > > To > > "The protocol extensions will" > > > > And in the numbers under change the wording to probably" > > "1. Define a table range query" > > "2. Define a table append" > > "3. Define additional..." > > > > 3. For the protocol extension also please add: > > "4. Define data packing rule for bitmap datatype". > > Although a suggestion is defined in the model, this detail should reside in > > the protocol document. > > > Done for both items. > > > 4. The Inter-FE Connectivity is written twice - delete one. > > I think this was a cutnpaste error from local copy to email client; on > the file residing on my disk it looks fine. > > cheers, > jamal > > Regards, > > Evangelos Haleplidis. > > > >> -----Original Message----- > >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > >> Behalf Of Jamal Hadi Salim > >> Sent: Wednesday, March 13, 2013 12:16 PM > >> To: forces@ietf.org > >> Subject: [forces] Recharter > >> > >> Folks, > >> > >> We have a recharter! > >> Thanks to Adrian and everyone in the WG who worked hard to get us here. > >> The strawman charter was posted yesterday, the wording is highly likely > >> to change. > >> Please provide comments on the wording etc. > >> > >> cheers, > >> jamal > >> _______________________________________________ > >> forces mailing list > >> forces@ietf.org > >> https://www.ietf.org/mailman/listinfo/forces > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Mon Mar 25 06:20:00 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20D321F845E for ; Mon, 25 Mar 2013 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ufrzdwx8Cwo for ; Mon, 25 Mar 2013 06:20:00 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD621F845D for ; Mon, 25 Mar 2013 06:19:59 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id it16so428047bkc.11 for ; Mon, 25 Mar 2013 06:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=fGxC9Lzabo4g7JAS7qq3WACWtEmB29eJveXUNSTmEsA=; b=Kc3ZJweGxV5P/f9Jv1mbTAShvtO3zO4UjcwdeR5CafyEKqDKnsEXeQ8YRU5hEZUoe2 R+CeBqPrlXw3yyZu2ER52Uka3+hzGQUJJ6wkH1QBjj3waYsez9uECgX24hYfHUqBK3FV DcfJCJ7Rk8WNA4pYPx3P5AVcwcoQEFgPXGgEN3LHmzVP/g4WzCm8sjG8bTvPXh9eRdhT oFvtT2JBmX5ULWTm+pChnTxM20Oz7pgUgMLF7wm1jjIDa2ApSeUd77F/Bkf3RqTc1k64 eOps4pQ2z1QAjGv3p74UeoXIPVSCol058CQKsnwOMSPFCwjqVYX9THb4FT9kEGSWWEJp +dHw== X-Received: by 10.205.38.3 with SMTP id tg3mr955438bkb.66.1364217598331; Mon, 25 Mar 2013 06:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.156.210 with HTTP; Mon, 25 Mar 2013 06:19:38 -0700 (PDT) In-Reply-To: <5149D893.6050801@stevecrocker.com> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> <5147305A.1080205@stevecrocker.com> <8D15A2BAF93E9C49AB037A0647E5FA6405F52B68@eusaamb105.ericsson.se> <5149D893.6050801@stevecrocker.com> From: Jamal Hadi Salim Date: Mon, 25 Mar 2013 09:19:38 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnO4w8F7HIYmYT7SrVfO10QfILJ3FpUeKg31gVAxezsF81/vLEvfqk5WubR7W+Umx6Er4uD Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 25 Mar 2013 13:20:00 -0000 On Wed, Mar 20, 2013 at 11:41 AM, Joel wrote: > Where it gets more complicated than the picture below is when one looks at > backplanes that are ATCA or similar (Ethernet, wit cards from different > vendors), or chipmakers wanting to use standard interfaces in and out of > their chip (e.g. Ethernet). > I think Joel states it well. Although ethernet could be looked at as the universal "backplane"; it is not the only one. At minimal we need to mention the other possibilites. Note: ability to allow an ecosystem of chip/board/box vendors is/was the underlying driver for ForCES. I should be able to buy a chip from Vendor X and plugin into my board using their drivers and treat it as an LFB or even an FE. Likewise, i should be able to buy a board from Vendor Y with network function A and plugin into my NE. I should be able to buy a box from Vendor Z .. etc. > Having said that, I think it is much clearer if the document focuses on the > inter-fe problem with separate boxes as the canonical case. The other cases > can be mention as furhter examples where this work may apply. Doing it the > other way looks like we are trying to slide a big deal under a hole in the > existing limits. > Board-to-board vs box-to-box should not be much different. I think if we focus on ethernet and have one or two other docs describe other tunneling approaches over IP satisfy the same requirements, we should be in good shape. cheers, jamal From hadi@mojatatu.com Mon Mar 25 06:26:14 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762B221F8E66 for ; Mon, 25 Mar 2013 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b8exiryMKUu for ; Mon, 25 Mar 2013 06:26:14 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id D149821F8D8E for ; Mon, 25 Mar 2013 06:26:13 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id q16so434483bkw.41 for ; Mon, 25 Mar 2013 06:26:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=/NTEDxKNoiqDEkKT5ZfIxj76xtB1dIOuKZfOPs1v37o=; b=YPxfiNP+EKtA20zfns6qGoDQfFYNJrUd9rMzvrRv16bdwtaleg4FQxTRCwfrJtKnQM KbbZY+8poDo7YfGzM5W1UQFYSyWnW6RuGRfWD3x2xpdQbup2YlbYJQSp9oZsPiWKmcN6 NslE8W8ce0c7JAIOz71JGqbP3v5zVdDq/GE8QOTFDqFLxIcE5e10RUifVyP/Y9KAy3RS 2cjGGx1DPySOvRCBTCTEI+9Z9FzEFuYpvNmzINBFEfYwGpaTws0YMMZM/+EDKQrvlOS0 N4uq68NKB+tcjpWTqAFOyftHB+J/aqrqZyyV7NsbHC4Gw3b8WCcN9EAc0EgfmWZSwzHI wnyQ== X-Received: by 10.205.131.197 with SMTP id hr5mr5419268bkc.124.1364217972543; Mon, 25 Mar 2013 06:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.156.210 with HTTP; Mon, 25 Mar 2013 06:25:52 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 25 Mar 2013 09:25:52 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlDDTYd9cKYHbMWjS7QiXHi8Cl4/vg03gJTbqg5FcDzr1YqmvRtWJAIJqnlBsEk/CM2eCl2 Cc: Jae.won.chung@one.verizon.com Subject: [forces] 86 IETF minutes 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: Mon, 25 Mar 2013 13:26:14 -0000 Much thanks to Jae for taking these detailed excellent minutes. https://www.ietf.org/proceedings/86/minutes/minutes-86-forces Jae had sent them to me during IETF week, but i just wanted to take a quick look before posting. cheers, jamal From dave.hood@ericsson.com Mon Mar 25 06:59:28 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C3F21F8C9B for ; Mon, 25 Mar 2013 06:59:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwrzk5FpeD9v for ; Mon, 25 Mar 2013 06:59:24 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60C21F8C9A for ; Mon, 25 Mar 2013 06:59:20 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-3f-51505834ddbf Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D6.8C.02430.43850515; Mon, 25 Mar 2013 14:59:16 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 09:59:15 -0400 From: Dave Hood To: Jamal Hadi Salim , Joel Thread-Topic: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 Thread-Index: AQHOI+vsq3VMkgM2l0Ss/iWBMJTppJiuwOgA///0pYCAAEhVgIAHtCEA///H4BA= Date: Mon, 25 Mar 2013 13:59:15 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA6405F5814E@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EB11@eusaamb105.ericsson.se> <689CE984BDBA8B4CAF3EA6E2CDC5CACB011996C113@FHDP1LUMXC7V31.us.one.verizon.com> <5147305A.1080205@stevecrocker.com> <8D15A2BAF93E9C49AB037A0647E5FA6405F52B68@eusaamb105.ericsson.se> <5149D893.6050801@stevecrocker.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXSPt65JRECgwdojqhanF89gtnj4Zjab xe2te9gsdm38yuTA4rFkyU8mj2231rJ6zD56jMmj9btoAEsUl01Kak5mWWqRvl0CV0bfl+Ws BRP5K9pnf2NuYJzA08XIwSEhYCLxtUGri5ETyBSTuHBvPRuILSRwhFHi+033LkYuIHs5o8TV +c+YQRJsAhoSTy5NZgKxRQTcJM5uu8kIYjML5EosOrgHrFlYIFRiz45DUDVhEtMWt7OD7BIR 8JP4ecgYJMwioCrx9to8VhCbV8BXomVuKxvErmYWiY+Xv4Pt4hQIlLi/eA+YzQh03PdTa5gg dolL3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJb7PecQCUa8jsWD3JzYIW1ti2cLXzBCLBSVO znzCMoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGBpsYgZF0TIJNdwfjnpeWhxilOViU xHmDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDctrP4UuJ2X7+Ieaer47K3bvUJeLw9 xrt33jWT/pS0rIbglROE59gI6D+NN+KT3KbU9Jzt1sJHk0482L/0s17y2bStB+/OOWKSxZrL tHm3vIqDy1uzIy9n/9R1NBRUcVslbLR3+RwPdlVPvv2Je/5+mc/A8a29Qm0XS0DdjWwem9NK se8m+D5XYinOSDTUYi4qTgQALes4LXICAAA= Cc: "forces@ietf.org" Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-interfelfb-01 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, 25 Mar 2013 13:59:28 -0000 Agreed. Board-board or box-box is a side issue; the point is to be able to = tunnel, and Ethernet is a good start. Dave -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 Sent: Monday, March 25, 2013 6:20 AM To: Joel Cc: Dave Hood; Joachimpillai, Damascene M; forces@ietf.org Subject: Re: [forces] Comments, questions: draft-joachimpillai-forces-inter= felfb-01 On Wed, Mar 20, 2013 at 11:41 AM, Joel wrote: > Where it gets more complicated than the picture below is when one=20 > looks at backplanes that are ATCA or similar (Ethernet, wit cards from=20 > different vendors), or chipmakers wanting to use standard interfaces=20 > in and out of their chip (e.g. Ethernet). > I think Joel states it well. Although ethernet could be looked at as the un= iversal "backplane"; it is not the only one. At minimal we need to mention the other possibilites. Note: ability to allo= w an ecosystem of chip/board/box vendors is/was the underlying driver for = ForCES. I should be able to buy a chip from Vendor X and plugin into my board using= their drivers and treat it as an LFB or even an FE. Likewise, i should be = able to buy a board from Vendor Y with network function A and plugin into m= y NE. I should be able to buy a box from Vendor Z .. etc. > Having said that, I think it is much clearer if the document focuses=20 > on the inter-fe problem with separate boxes as the canonical case. =20 > The other cases can be mention as furhter examples where this work may=20 > apply. Doing it the other way looks like we are trying to slide a big=20 > deal under a hole in the existing limits. > Board-to-board vs box-to-box should not be much different. I think if we fo= cus on ethernet and have one or two other docs describe other tunneling app= roaches over IP satisfy the same requirements, we should be in good shape. cheers, jamal From internet-drafts@ietf.org Thu Mar 28 18:10:04 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E474421F87B1; Thu, 28 Mar 2013 18:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXhQkIDn1Gaw; Thu, 28 Mar 2013 18:10:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4419D21F8739; Thu, 28 Mar 2013 18:10:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130329011004.24127.78640.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2013 18:10:04 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-lfb-lib-12.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, 29 Mar 2013 01:10:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Logical Function Block (LFB) Library Author(s) : Weiming Wang Evangelos Haleplidis Kentaro Ogawa Chuanhuang Li Halpern Joel Filename : draft-ietf-forces-lfb-lib-12.txt Pages : 115 Date : 2013-03-28 Abstract: This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-lfb-lib-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-lfb-lib-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmwang2001@hotmail.com Thu Mar 28 18:49:33 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D821F8801 for ; Thu, 28 Mar 2013 18:49:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRXmjG8h9g4b for ; Thu, 28 Mar 2013 18:49:33 -0700 (PDT) Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by ietfa.amsl.com (Postfix) with ESMTP id 137AA21F87C5 for ; Thu, 28 Mar 2013 18:49:30 -0700 (PDT) Received: from BLU0-SMTP31 ([65.55.111.136]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Mar 2013 18:49:29 -0700 X-EIP: [GwsUjNYTC3KVl1A6xzvl3BqZrsBTUISc] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([60.186.182.236]) by BLU0-SMTP31.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Mar 2013 18:49:28 -0700 From: "Wang,Weiming" To: Date: Fri, 29 Mar 2013 09:49:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 29 Mar 2013 01:49:28.0248 (UTC) FILETIME=[A6175B80:01CE2C1F] Subject: [forces] Fw: New Version Notification for draft-ietf-forces-lfb-lib-12.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, 29 Mar 2013 01:49:33 -0000 QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWItMTIudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaW1pbmcgV2FuZyBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogZHJhZnQtaWV0Zi1mb3JjZXMt bGZiLWxpYg0KUmV2aXNpb246IDEyDQpUaXRsZTogRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb24gQmxv Y2sgKExGQikgTGlicmFyeQ0KQ3JlYXRpb24gZGF0ZTogMjAxMy0wMy0yOQ0KR3JvdXA6IGZvcmNl cw0KTnVtYmVyIG9mIHBhZ2VzOiAxMTUNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi0xMi50eHQNClN0 YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWZvcmNlcy1sZmItbGliDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWItMTINCkRpZmY6ICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi0xMg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBiYXNpYyBjbGFzc2VzIG9mIExv Z2ljYWwgRnVuY3Rpb24gQmxvY2tzIChMRkJzKQ0KICAgdXNlZCBpbiB0aGUgRm9yd2FyZGluZyBh bmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykuICBUaGUNCiAgIGJhc2ljIExG QiBjbGFzc2VzIGFyZSBkZWZpbmVkIGFjY29yZGluZyB0byBGb3JDRVMgRkUgbW9kZWwgYW5kIEZv ckNFUw0KICAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMsIGFuZCBhcmUgc2NvcGVkIHRvIG1lZXQg cmVxdWlyZW1lbnRzIG9mDQogICB0eXBpY2FsIHJvdXRlciBmdW5jdGlvbnMgYW5kIGNvbnNpZGVy ZWQgYXMgdGhlIGJhc2ljIExGQiBsaWJyYXJ5IGZvcg0KICAgRm9yQ0VTLiAgVGhlIGxpYnJhcnkg aW5jbHVkZXMgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgTEZCcyBhbmQgdGhlDQogICBYTUwgZGVm aW5pdGlvbnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo=