From hadi@mojatatu.com Sun Feb 2 03:06:41 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB521A00BF for ; Sun, 2 Feb 2014 03:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_OZKyVR2cVO for ; Sun, 2 Feb 2014 03:06:40 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB6991A00BE for ; Sun, 2 Feb 2014 03:06:39 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hu8so4151515vcb.29 for ; Sun, 02 Feb 2014 03:06:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=VcotaKuKYtkt7C6GDTOswU5kZscfJqTAzcjlBG9TBig=; b=J5A6XCD6CPpg0bMZDw0tpc8PCkxZ5zjNje5mjCyVfjZXVrkH4byZ/f+UzvnrCT9XHh Sguz9Boyt/QZv96vP3MlkBPocSyG2E7Uu8WK3JD70zjcGdQTk0qp6ZoCjj8P7OC+4FQw V8qI67xjLrgdpxv8ZvOpc+yII4xAZSdy8jCst+cISw64KTcZUIvkPVarOUx+tkkQjT3U tzddXVsGsYdl7T1uwgKykGqk4m4Mw7GI24xUU8jjKzZSF/j3gz2Fs//A7+qHrCarzs0o y9dQBY0yQHn/JCopzQv3ESisSb1PD2YasyrjHiZ+Y03cfzKCHDXWMwb37A49YMy4ObrP xJ/Q== X-Gm-Message-State: ALoCoQnmzHDef+PsnHDX5vG13gkSpBv2znRIrWG1MvCmLvGi7howqMIcEZbCSmTksCmsFV9amkip X-Received: by 10.220.97.145 with SMTP id l17mr203944vcn.35.1391339195334; Sun, 02 Feb 2014 03:06:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Sun, 2 Feb 2014 03:06:15 -0800 (PST) From: Jamal Hadi Salim Date: Sun, 2 Feb 2014 06:06:15 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] On generic KEYS X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 11:06:41 -0000 Folks, We are in the process of implementing a control app and have run into a "bottleneck". To illustrate the challenge at stake, lets consider a switch/bridge fdb table. In the simple case, such a table will have 3 columns {MAC, VLANid, port} where port is the egress point to forward a packet with a matching MAC + VLANid. Such a table on the datapath is looked up by MAC + optional VLANid. The LFB fdb table reference is therefore specified to have a key of {MAC, VLANid}. ForCES allows me to reference table rows by table index, range or key. The table index or range of indices is meaningful for north-south (control-datapath) transactions and the key selection is meaningful in both east-west (datapath) and north-south. Consider the scenario where i have multiple bridges/switches on an FE. One i am interested in ("br0") has 100K active fdb entries. Say about 20% (thats 20K) point to a port "eth0" - and I want to delete all of those specific entries. I would need a large amount of data on the wire to request for those 20K entries to be deleted. I could go and specify an extra key that is meaningful only from north-south for this specific LFB but that in itself does not solve the general problem. In our implementation, we are considering using a generic "key" that is meaningful in the north-south direction. This key will have arbitrary fields representing columns present on the specified table. From my example above, the key contents could have one or more of {MAC, VLANid, port} components. My problem above is resolved by expressing a {port} with value of "eth0". In order not to introduce any new constructs, I would like to propose that we allow for KEY with id of 0 to represent such content. IOW, the keyid of 0 becomes reserved for such a purpose. Such a change is small and timely because we are still in the process of pushing protocol and model extensions. Thoughts? cheers, jamal From joel@stevecrocker.com Sun Feb 2 06:02:20 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96DD1A00D3 for ; Sun, 2 Feb 2014 06:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdtgNcYC-G1c for ; Sun, 2 Feb 2014 06:02:19 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id B01CF1A000A for ; Sun, 2 Feb 2014 06:02:19 -0800 (PST) Received: from dummy.name; Sun, 02 Feb 2014 14:02:15 +0000 Message-ID: <52EE4FE6.7080208@stevecrocker.com> Date: Sun, 02 Feb 2014 09:02:14 -0500 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jamal Hadi Salim , "forces@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [forces] On generic KEYS X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:02:21 -0000 While that is a small change from a protocol perspective, and very effective from the controller perspective, it places significant requirements on the FE. It has to be prepared to search the tables for any field combination. This is exactly the opposite of the intended distribution of intelligence. This is not an operation that has to take place quickly, since simply disabling eth0 will take care of the problem in this simple case. In more complex cases, I admit there may be challenges. I would note that rotuers do not expect their line cards to be able to perform these kinds of matches. Yours, Joel On 2/2/14, 6:06 AM, Jamal Hadi Salim wrote: > Folks, > > We are in the process of implementing a control app and have run into > a "bottleneck". > > To illustrate the challenge at stake, lets consider a switch/bridge fdb table. > In the simple case, such a table will have 3 columns {MAC, VLANid, port} > where port is the egress point to forward a packet with a matching > MAC + VLANid. > Such a table on the datapath is looked up by MAC + optional VLANid. > The LFB fdb table reference is therefore specified to have a key of > {MAC, VLANid}. > ForCES allows me to reference table rows by table index, range or key. > The table index or range of indices is meaningful for north-south > (control-datapath) transactions and the key selection is meaningful in > both east-west (datapath) and north-south. > > Consider the scenario where i have multiple bridges/switches on an FE. > One i am interested in ("br0") has 100K active fdb entries. Say about 20% > (thats 20K) point to a port "eth0" - and I want to delete all of those specific > entries. > I would need a large amount of data on the wire to request for those 20K > entries to be deleted. > I could go and specify an extra key that is meaningful only from north-south > for this specific LFB but that in itself does not solve the general problem. > > In our implementation, we are considering using a generic "key" that is > meaningful in the north-south direction. This key will have arbitrary > fields representing columns present on the specified table. From my example > above, the key contents could have one or more of {MAC, VLANid, port} > components. > My problem above is resolved by expressing a {port} with value of "eth0". > In order not to introduce any new constructs, I would like to propose > that we allow for KEY with id of 0 to represent such content. > IOW, the keyid of 0 becomes reserved for such a purpose. > > Such a change is small and timely because we are still in the process of > pushing protocol and model extensions. > > Thoughts? > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Sun Feb 2 06:33:33 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9B1A00DB for ; Sun, 2 Feb 2014 06:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVJmTBPGTqtf for ; Sun, 2 Feb 2014 06:33:31 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 37EE41A00D9 for ; Sun, 2 Feb 2014 06:33:31 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id cz12so4374915veb.29 for ; Sun, 02 Feb 2014 06:33:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z9Pc5ZzN9yy84Y7x5GpSqFLq+nPT/E4Eyfk0HQIlZ54=; b=hn3Wvn0lXdba+KsR26N1rZdxJsE5vjd8bqU+W6AoG18i0DR6zdOE/iJ17qSFlAfNQ3 lJnfWuIProg4c7vS3cdl7rApwOYS0em2C/uuVu4l1Vh3S3g4lv+GmijnqQMUU7H6+msP cbKjOZyvm4M31FtCEdl7+NvOS8VHwzshhqCIKFSGMZza07hIR6vRyPQKLHCrFCFKLhr9 Hqfzt5XF9ceX83ERLFKjFsSwUA/YJei5YjX0stx5WX9XR8AW+NnY0kydqlU0NrMIuzK7 Jh9JvaFLfA2ARb/4WK258U0YVpZ0WflGeF/n0AaeHz3Z62gjtjFip2hvgR6a2JtivOsl dUng== X-Gm-Message-State: ALoCoQmijM7J0eBjyBUjr9g7SItpyL0LKmpGLhbd6rO43baV4mDMdURpotzVKvB00z3vvaa25MWk X-Received: by 10.52.110.201 with SMTP id ic9mr20790832vdb.22.1391351606442; Sun, 02 Feb 2014 06:33:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Sun, 2 Feb 2014 06:33:06 -0800 (PST) In-Reply-To: <52EE4FE6.7080208@stevecrocker.com> References: <52EE4FE6.7080208@stevecrocker.com> From: Jamal Hadi Salim Date: Sun, 2 Feb 2014 09:33:06 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] On generic KEYS X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:33:33 -0000 I worried about the message getting lost via the one sample;-> So assume the "complex case" you alluded to as a generic reason. Assume also we discover what the capability of a specific FE is and from a control plane view we get to choose what gets sent to the FE in terms of the request. On Sun, Feb 2, 2014 at 9:02 AM, Joel wrote: > While that is a small change from a protocol perspective, and very effective > from the controller perspective, it places significant requirements on the > FE. It has to be prepared to search the tables for any field combination. > This is exactly the opposite of the intended distribution of intelligence. > I am not expecting every FE to be able to handle this and we have ways to do with capabilities of FEs. But for those FEs that are capable, i would hope we can enable them. Example: one could make the query to the Linux kernel with extra filters on a variety of LFBs. ForCES should be able to take advantage of that (instead of sending many queries and doing more filtering computation on the CE). > This is not an operation that has to take place quickly, No Joel - thats absolutely not the case for what i am trying to do but i worry i am going to digress. I dont want eth0 to go down and i want this done quickly. Just ignore this example and focus on the generic case. > since simply > disabling eth0 will take care of the problem in this simple case. In more > complex cases, I admit there may be challenges. I am more interested in the complex cases. I dont want to go on the distraction of the example anymore. > I would note that rotuers do not expect their line cards to be able to > perform these kinds of matches. > And i dont expect classical/legacy devices to be able to do this. Side/tangent note: I should point out that even within software FEs these sort of lessons seem to come as an after-thought. As example, in Linux theres a lot of filtering that occurs in user space after the kernel has provided information. Over the years hacks are being added (eg in some case you can download a little bpf program to the kernel to filter out certain types of responses because the interfaces were wrong to begin with and the API is already in the wild). > Yours, > Joel > > > On 2/2/14, 6:06 AM, Jamal Hadi Salim wrote: >> >> Folks, >> >> We are in the process of implementing a control app and have run into >> a "bottleneck". >> >> To illustrate the challenge at stake, lets consider a switch/bridge fdb >> table. >> In the simple case, such a table will have 3 columns {MAC, VLANid, port} >> where port is the egress point to forward a packet with a matching >> MAC + VLANid. >> Such a table on the datapath is looked up by MAC + optional VLANid. >> The LFB fdb table reference is therefore specified to have a key of >> {MAC, VLANid}. >> ForCES allows me to reference table rows by table index, range or key. >> The table index or range of indices is meaningful for north-south >> (control-datapath) transactions and the key selection is meaningful in >> both east-west (datapath) and north-south. >> >> Consider the scenario where i have multiple bridges/switches on an FE. >> One i am interested in ("br0") has 100K active fdb entries. Say about 20% >> (thats 20K) point to a port "eth0" - and I want to delete all of those >> specific >> entries. >> I would need a large amount of data on the wire to request for those 20K >> entries to be deleted. >> I could go and specify an extra key that is meaningful only from >> north-south >> for this specific LFB but that in itself does not solve the general >> problem. >> >> In our implementation, we are considering using a generic "key" that is >> meaningful in the north-south direction. This key will have arbitrary >> fields representing columns present on the specified table. From my >> example >> above, the key contents could have one or more of {MAC, VLANid, port} >> components. >> My problem above is resolved by expressing a {port} with value of "eth0". >> In order not to introduce any new constructs, I would like to propose >> that we allow for KEY with id of 0 to represent such content. >> IOW, the keyid of 0 becomes reserved for such a purpose. >> >> Such a change is small and timely because we are still in the process of >> pushing protocol and model extensions. >> >> Thoughts? >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > From hadi@mojatatu.com Tue Feb 4 05:29:09 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B7A1A043E for ; Tue, 4 Feb 2014 05:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eumSpK0N6y7k for ; Tue, 4 Feb 2014 05:29:08 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id D46A81A0416 for ; Tue, 4 Feb 2014 05:29:07 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so5696790vcb.22 for ; Tue, 04 Feb 2014 05:29:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=dVMxFj1nQ7iEkTEw6anlzvwb7O+O3X5IUzDOYsdg8CM=; b=V3DkDv0IyA6sBjvnONqTDff2deG0OXTAQjKhAOK/ABPKGR7Ekqj9X3YHeXm5INeusA LwpyTosC6CqSbe8b6w8H7WbRY6vOCQTEPvq3CU11SqfYqBILZyQhLlYhbqkMo2vd1qAg GwyXttmsV6FaC1TZ3pPLu+1GwTe8rEOyMHisUwVBMjP7xlUvRbMnodd6xQPDlwuYZhZa cewAei602rnvX3felysp+WiT4vsNusttq+vuBCXnBA/qEWQQIKxdjxX1m3Dskc6k4Au3 WZq3EUqqbmMLC2vqnDZLNdRVI+faPHT5h3zKrfPXKoDalynPCfttwQ26m4v7hpmHNp39 7a1A== X-Gm-Message-State: ALoCoQkVRbLAQHLyZ2NhJDqPd2GfV4D1+1DG/FzVTxalfHHzbC0bLCt33vsTlvNS5x8tD0u1GB1G X-Received: by 10.220.247.68 with SMTP id mb4mr86238vcb.37.1391520547239; Tue, 04 Feb 2014 05:29:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 4 Feb 2014 05:28:47 -0800 (PST) From: Jamal Hadi Salim Date: Tue, 4 Feb 2014 08:28:47 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:29:09 -0000 I feel need for Model extension to introduce Events for FEO LFB class instantiation and destruction. My use case - I wrote a simple monitor app. It does the following: a) subscribe to listen to FEs associating and disassociating b) When an FE associates to the controller, probe it for all all LFBs it supports and what versions c) subscribe to events on LFB instances of interest At this point we have state for FE + LFB instances stored within the App. We get events and in the simple case we just log them (but think of refreshing a GUI etc). My problem: I have no way of asynchronously knowing if an LFB instance to which i am subscribed-to for events is destroyed. Or a new one is instantiated so i can subscribe-to events should i need to. This event will help alleviate that pain. cheers, jamal From joel@stevecrocker.com Tue Feb 4 13:33:35 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4001A0155 for ; Tue, 4 Feb 2014 13:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAysDNCRg-QH for ; Tue, 4 Feb 2014 13:33:34 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1373D1A012C for ; Tue, 4 Feb 2014 13:33:33 -0800 (PST) Received: from dummy.name; Tue, 04 Feb 2014 21:33:33 +0000 Message-ID: <52F15CAC.5020600@stevecrocker.com> Date: Tue, 04 Feb 2014 16:33:32 -0500 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jamal Hadi Salim , "forces@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 21:33:35 -0000 There seem to be two sub-cases of this, one of which is rare, and the other of which seems irrelevant. There is the rare case of the FE creating LFB instances on its own. This is legal, and arguably an event to detect this would be useful. But I can not imagine this is what you are looking for. The other possibility is that your monitor is distinct from the CE, and you want to know about CE creation and deletion of the LFB instances. The only problem with taht is that by architecture we currently don't have provision for interacting with multiple CEs. If there is itnerest from I2RS we may need to address that gap, but without addressing that I don't see how something can be subscribed to FE events about CE actions. Yours, Joel On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote: > I feel need for Model extension to introduce Events for > FEO LFB class instantiation and destruction. > > My use case - I wrote a simple monitor app. It does the following: > > a) subscribe to listen to FEs associating and disassociating > b) When an FE associates to the controller, probe it for all > all LFBs it supports and what versions > c) subscribe to events on LFB instances of interest > > At this point we have state for FE + LFB instances stored within > the App. We get events and in the simple case we just log them > (but think of refreshing a GUI etc). > My problem: > I have no way of asynchronously knowing if an LFB instance > to which i am subscribed-to for events is destroyed. Or a new one > is instantiated so i can subscribe-to events should i need to. > > This event will help alleviate that pain. > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Wed Feb 5 03:44:02 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4E1A00B2 for ; Wed, 5 Feb 2014 03:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX0Y2epXFLoJ for ; Wed, 5 Feb 2014 03:44:01 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3A39E1A00E8 for ; Wed, 5 Feb 2014 03:44:01 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id x14so184932vbb.36 for ; Wed, 05 Feb 2014 03:44:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eOhoZ98U7oOskN57rsxQPpjP4+cx5hwlKqJguY9RpTw=; b=CdMayWJzIXxzRPdsSCsf8HVtuvkX6yxKapIlwr1CWyllEGDKsxecgXXf1ldT3cQMmo MmHiy5GgqoZj5RrPEYBNyCru/glDQAabSxy7xf2PtFbZPmHNFHWOEqugHZE4RyhllWWB kCNVLYNqm1OSCLHehUSXHh38V8WYsBgL+ag6+mwNHhP+0XCmp9nbA22nAgg6HN397MEX 9V7Y5NOOVv4mXbiXHEHtF5LlrLJvVAMryPYVq1ZrjIZUpQ93Wl9MnNdG1lIgKkLc5jNW 9k+2aEufT7zfyPBraCG+LOt7DttdAXd0NQLMfxQTgSEGiq2+VZL3V4yyP3D4oiwbd64q SABg== X-Gm-Message-State: ALoCoQmLGdAbzVvPb5DdkGHRtwt3xkxsqha4mbSDTogGScgrmKIgD2vbv98P6z0N7HCoESBwvrMX X-Received: by 10.220.29.200 with SMTP id r8mr683917vcc.9.1391600640372; Wed, 05 Feb 2014 03:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Wed, 5 Feb 2014 03:43:39 -0800 (PST) In-Reply-To: <52F15CAC.5020600@stevecrocker.com> References: <52F15CAC.5020600@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 5 Feb 2014 06:43:39 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 11:44:02 -0000 Joel, I havent thought of the rare case you mention - but it would be taken care here as well. The scenario i described is not related to multiple CEs, rather multiple apps. In our implementation: We may have multiple applications talking to one or more CEs. The monitor example would be such an app which is passive, but other apps(eg a CLI) may be actively instantiating/destroying LFBs. In the case of multiple controllers, only the master of a specific CE is allowed to do writes to that FE. So apps will have to go via this sync point. cheers, jamal cheers, jamal On Tue, Feb 4, 2014 at 4:33 PM, Joel wrote: > There seem to be two sub-cases of this, one of which is rare, and the other > of which seems irrelevant. > > There is the rare case of the FE creating LFB instances on its own. This is > legal, and arguably an event to detect this would be useful. But I can not > imagine this is what you are looking for. > > > The other possibility is that your monitor is distinct from the CE, and you > want to know about CE creation and deletion of the LFB instances. The only > problem with taht is that by architecture we currently don't have provision > for interacting with multiple CEs. If there is itnerest from I2RS we may > need to address that gap, but without addressing that I don't see how > something can be subscribed to FE events about CE actions. > > Yours, > Joel > > On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote: >> >> I feel need for Model extension to introduce Events for >> FEO LFB class instantiation and destruction. >> >> My use case - I wrote a simple monitor app. It does the following: >> >> a) subscribe to listen to FEs associating and disassociating >> b) When an FE associates to the controller, probe it for all >> all LFBs it supports and what versions >> c) subscribe to events on LFB instances of interest >> >> At this point we have state for FE + LFB instances stored within >> the App. We get events and in the simple case we just log them >> (but think of refreshing a GUI etc). >> My problem: >> I have no way of asynchronously knowing if an LFB instance >> to which i am subscribed-to for events is destroyed. Or a new one >> is instantiated so i can subscribe-to events should i need to. >> >> This event will help alleviate that pain. >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > From hadi@mojatatu.com Wed Feb 5 03:46:58 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683FC1A00F0 for ; Wed, 5 Feb 2014 03:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgA53zHXtkPD for ; Wed, 5 Feb 2014 03:46:57 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id E76551A00B2 for ; Wed, 5 Feb 2014 03:46:56 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id p14so185370vbm.25 for ; Wed, 05 Feb 2014 03:46:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5rq/OwJzKBLCBrEYsO9h+i8pZslBO+p4tPqI6PaD8No=; b=f5TqnSsDkyOP77ZNLzMwv4HT4xJ/kgKx24reuq0rWKiHiZQ3AKPT1O6hV2Yh+k3MYC VJttWqdjy0MRh/2USssAFGbTxMx4fBwcCnoowl3IK/rHoGKOvNwXJdZZVCEVQBVHvhjG Ck4LuvJPuPS6FgkSfomAuaGUWfQsEgsBXLQPn4CctjKNIf7f86hXNJDEo03lpWPZeJlc q97INhYWNPTf7YMHkG7KBc4gHZe/dru+2pMYuy6F1q7PFgT/YPo/Fk+UC5jUMxwI9Opo K44U8fC2PlCJaEZW0AUaGzg2Zs1iLHUawoLzn2n1nkagLylYz0xKBVUwmg1K2ou2O4mV XCvw== X-Gm-Message-State: ALoCoQm9SRItkYEjDgGs3rtXU7Ntzpr2nMmnydXLv0lMyKDIoRjS/AQzEf9jWwaA8HNCfN3rKggS X-Received: by 10.52.170.3 with SMTP id ai3mr559785vdc.35.1391600815954; Wed, 05 Feb 2014 03:46:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Wed, 5 Feb 2014 03:46:35 -0800 (PST) In-Reply-To: References: <52F15CAC.5020600@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 5 Feb 2014 06:46:35 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 11:46:58 -0000 Meant: "only the master of a specific FE is allowed to do writes to that FE" Of course all other CEs will (read) receive events they subscribed to whether they are connected to the master or backup CE(s). (as per CEHA). cheers, jamal On Wed, Feb 5, 2014 at 6:43 AM, Jamal Hadi Salim wrote: > Joel, > I havent thought of the rare case you mention - but it would be taken care here > as well. The scenario i described is not related to multiple CEs, > rather multiple > apps. > In our implementation: > We may have multiple applications talking to one or more CEs. > The monitor example would be such an app which is passive, but other > apps(eg a CLI) may be actively instantiating/destroying LFBs. > In the case of multiple controllers, only the master of a specific CE is allowed > to do writes to that FE. So apps will have to go via this sync point. > > cheers, > jamal > > > cheers, > jamal > > > > > On Tue, Feb 4, 2014 at 4:33 PM, Joel wrote: >> There seem to be two sub-cases of this, one of which is rare, and the other >> of which seems irrelevant. >> >> There is the rare case of the FE creating LFB instances on its own. This is >> legal, and arguably an event to detect this would be useful. But I can not >> imagine this is what you are looking for. >> >> >> The other possibility is that your monitor is distinct from the CE, and you >> want to know about CE creation and deletion of the LFB instances. The only >> problem with taht is that by architecture we currently don't have provision >> for interacting with multiple CEs. If there is itnerest from I2RS we may >> need to address that gap, but without addressing that I don't see how >> something can be subscribed to FE events about CE actions. >> >> Yours, >> Joel >> >> On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote: >>> >>> I feel need for Model extension to introduce Events for >>> FEO LFB class instantiation and destruction. >>> >>> My use case - I wrote a simple monitor app. It does the following: >>> >>> a) subscribe to listen to FEs associating and disassociating >>> b) When an FE associates to the controller, probe it for all >>> all LFBs it supports and what versions >>> c) subscribe to events on LFB instances of interest >>> >>> At this point we have state for FE + LFB instances stored within >>> the App. We get events and in the simple case we just log them >>> (but think of refreshing a GUI etc). >>> My problem: >>> I have no way of asynchronously knowing if an LFB instance >>> to which i am subscribed-to for events is destroyed. Or a new one >>> is instantiated so i can subscribe-to events should i need to. >>> >>> This event will help alleviate that pain. >>> >>> cheers, >>> jamal >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> >> From hadi@mojatatu.com Wed Feb 5 04:06:02 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF7D1A0105 for ; Wed, 5 Feb 2014 04:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5owdIBg1i9f for ; Wed, 5 Feb 2014 04:06:00 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2B1A0103 for ; Wed, 5 Feb 2014 04:05:59 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id db12so205960veb.39 for ; Wed, 05 Feb 2014 04:05:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0KC9G3b+KumX71jPbSaKa78bVazenkyOAUiB9Q8KsHI=; b=WSXHaOB4jyfFmqH+tKc0gu0dV/6NwXb0vM3Vl/5RGt1UmyLRI3Df+lLxWBKyEpOMCF cTIN5p73oD69wWyopk9YsBOMazVrBFbVrq8JDyIgRqlnF4LKWAeEQftYlu7K7w9U5uNt her8i61gB3+wzs9kBNaY8kJ+hl2dXYdiZwamLn2YgcOtMeyKZ9JkT1bY/n3o1N6bAzkl FBLYxUfZojRKEfDvSRzhQZOYeTJV7V/nsiD5K+rZwOy6okPGMDbNEVLit5Z0YKetOMZ2 rp33Q7mSoMgVuDLt6U+FkXUSjATmCfqgOHDwO9+143Ei6VaknrdnxGKYWgWqnv48J3Jn szUg== X-Gm-Message-State: ALoCoQl08wxMtQyU2m12kroQSwgoC3ikJClajTOsdKhQXyN577hHhSFx20DnBWGHrss4/l58qExF X-Received: by 10.220.53.66 with SMTP id l2mr324753vcg.33.1391601958806; Wed, 05 Feb 2014 04:05:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Wed, 5 Feb 2014 04:05:38 -0800 (PST) In-Reply-To: References: <52F15CAC.5020600@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 5 Feb 2014 07:05:38 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 12:06:02 -0000 Ok, not that early in the morning and i am sipping my coffee but still typoing away;-> Meant: "of course all other Apps subscribed to a specific event whether connected to the master or backup CEs will receive events" cheers, jamal On Wed, Feb 5, 2014 at 6:46 AM, Jamal Hadi Salim wrote: > Meant: > "only the master of a specific FE is allowed to do writes to that FE" > Of course all other CEs will (read) receive events they subscribed to whether > they are connected to the master or backup CE(s). > (as per CEHA). > > cheers, > jamal > > On Wed, Feb 5, 2014 at 6:43 AM, Jamal Hadi Salim wrote: >> Joel, >> I havent thought of the rare case you mention - but it would be taken care here >> as well. The scenario i described is not related to multiple CEs, >> rather multiple >> apps. >> In our implementation: >> We may have multiple applications talking to one or more CEs. >> The monitor example would be such an app which is passive, but other >> apps(eg a CLI) may be actively instantiating/destroying LFBs. >> In the case of multiple controllers, only the master of a specific CE is allowed >> to do writes to that FE. So apps will have to go via this sync point. >> >> cheers, >> jamal >> >> >> cheers, >> jamal >> >> >> >> >> On Tue, Feb 4, 2014 at 4:33 PM, Joel wrote: >>> There seem to be two sub-cases of this, one of which is rare, and the other >>> of which seems irrelevant. >>> >>> There is the rare case of the FE creating LFB instances on its own. This is >>> legal, and arguably an event to detect this would be useful. But I can not >>> imagine this is what you are looking for. >>> >>> >>> The other possibility is that your monitor is distinct from the CE, and you >>> want to know about CE creation and deletion of the LFB instances. The only >>> problem with taht is that by architecture we currently don't have provision >>> for interacting with multiple CEs. If there is itnerest from I2RS we may >>> need to address that gap, but without addressing that I don't see how >>> something can be subscribed to FE events about CE actions. >>> >>> Yours, >>> Joel >>> >>> On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote: >>>> >>>> I feel need for Model extension to introduce Events for >>>> FEO LFB class instantiation and destruction. >>>> >>>> My use case - I wrote a simple monitor app. It does the following: >>>> >>>> a) subscribe to listen to FEs associating and disassociating >>>> b) When an FE associates to the controller, probe it for all >>>> all LFBs it supports and what versions >>>> c) subscribe to events on LFB instances of interest >>>> >>>> At this point we have state for FE + LFB instances stored within >>>> the App. We get events and in the simple case we just log them >>>> (but think of refreshing a GUI etc). >>>> My problem: >>>> I have no way of asynchronously knowing if an LFB instance >>>> to which i am subscribed-to for events is destroyed. Or a new one >>>> is instantiated so i can subscribe-to events should i need to. >>>> >>>> This event will help alleviate that pain. >>>> >>>> cheers, >>>> jamal >>>> _______________________________________________ >>>> forces mailing list >>>> forces@ietf.org >>>> https://www.ietf.org/mailman/listinfo/forces >>>> >>> From joel@stevecrocker.com Wed Feb 5 07:50:33 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2358B1A0214 for ; Wed, 5 Feb 2014 07:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5pz1vR5ETaK for ; Wed, 5 Feb 2014 07:50:31 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id E19B21A0207 for ; Wed, 5 Feb 2014 07:50:20 -0800 (PST) Received: from dummy.name; Wed, 05 Feb 2014 15:50:20 +0000 Message-ID: <52F25DBC.6080001@stevecrocker.com> Date: Wed, 05 Feb 2014 10:50:20 -0500 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jamal Hadi Salim References: <52F15CAC.5020600@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" Subject: Re: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:50:33 -0000 THe question of the archtiecture of the interaction of applications with the controller is a layer above that at which the ForCES protocol operates. Specifically, the protocol should not be generating events which are meaningless to the CE, just so the CE can pass them on to apps. If the CE wants to do that, it should do so by local means. Yours, Joel On 2/5/14, 6:43 AM, Jamal Hadi Salim wrote: > Joel, > I havent thought of the rare case you mention - but it would be taken care here > as well. The scenario i described is not related to multiple CEs, > rather multiple > apps. > In our implementation: > We may have multiple applications talking to one or more CEs. > The monitor example would be such an app which is passive, but other > apps(eg a CLI) may be actively instantiating/destroying LFBs. > In the case of multiple controllers, only the master of a specific CE is allowed > to do writes to that FE. So apps will have to go via this sync point. > > cheers, > jamal > > > cheers, > jamal > > > > > On Tue, Feb 4, 2014 at 4:33 PM, Joel wrote: >> There seem to be two sub-cases of this, one of which is rare, and the other >> of which seems irrelevant. >> >> There is the rare case of the FE creating LFB instances on its own. This is >> legal, and arguably an event to detect this would be useful. But I can not >> imagine this is what you are looking for. >> >> >> The other possibility is that your monitor is distinct from the CE, and you >> want to know about CE creation and deletion of the LFB instances. The only >> problem with taht is that by architecture we currently don't have provision >> for interacting with multiple CEs. If there is itnerest from I2RS we may >> need to address that gap, but without addressing that I don't see how >> something can be subscribed to FE events about CE actions. >> >> Yours, >> Joel >> >> On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote: >>> >>> I feel need for Model extension to introduce Events for >>> FEO LFB class instantiation and destruction. >>> >>> My use case - I wrote a simple monitor app. It does the following: >>> >>> a) subscribe to listen to FEs associating and disassociating >>> b) When an FE associates to the controller, probe it for all >>> all LFBs it supports and what versions >>> c) subscribe to events on LFB instances of interest >>> >>> At this point we have state for FE + LFB instances stored within >>> the App. We get events and in the simple case we just log them >>> (but think of refreshing a GUI etc). >>> My problem: >>> I have no way of asynchronously knowing if an LFB instance >>> to which i am subscribed-to for events is destroyed. Or a new one >>> is instantiated so i can subscribe-to events should i need to. >>> >>> This event will help alleviate that pain. >>> >>> cheers, >>> jamal >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> >> From hadi@mojatatu.com Wed Feb 5 13:35:34 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9EA1A0211 for ; Wed, 5 Feb 2014 13:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7T014xi6Y2v for ; Wed, 5 Feb 2014 13:35:32 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 824B41A01D1 for ; Wed, 5 Feb 2014 13:35:32 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so792008vcb.27 for ; Wed, 05 Feb 2014 13:35:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1Xows+Q7Ba4PrE2az+CM/ZHCizujr/oOhZoDdluJEPs=; b=F4g0nysuPcrLl4AMoByRUmm/2Pz0s556kGtkyO153JeSEOa4E/HUj7qjWie7sSFpJp yfv/3GOBEunyaRRSEogzW0bqcfzRjZtkqy73lHSMowVXqK5zyr3C1ok7o2tT7ybfGG7M 2ruECJ6ynXn0xBlr7bFKdwhGtNdRkxDssdiN5HEKlpMbkZxykNHnunIAZ2dS0qMUtO1h zyI+hIEvvVBvXQr6DWnAAxJ5U/DGcG1JczuAnKXvZChws/ZlgnNrXAJpKIVjgbvQTeF3 3lJHDhxTlOnHtGe62keMyJhmAXQyg1eA4nOPebtnBjxKnjlqyXYzRsSE1skzV2t0cqT/ cW9Q== X-Gm-Message-State: ALoCoQlokIgrs7XRtCUxOJYDmM3SElG3h9JmHFkAuKvpwd6geGBve3t0/PKtKYNciSzdQJOy1rlt X-Received: by 10.58.69.111 with SMTP id d15mr2478270veu.3.1391636131441; Wed, 05 Feb 2014 13:35:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Wed, 5 Feb 2014 13:35:11 -0800 (PST) In-Reply-To: <52F25DBC.6080001@stevecrocker.com> References: <52F15CAC.5020600@stevecrocker.com> <52F25DBC.6080001@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 5 Feb 2014 16:35:11 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] model request X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:35:34 -0000 On Wed, Feb 5, 2014 at 10:50 AM, Joel wrote: > THe question of the archtiecture of the interaction of applications with the > controller is a layer above that at which the ForCES protocol operates. This is true. > Specifically, the protocol should not be generating events which are > meaningless to the CE, just so the CE can pass them on to apps. If the CE > wants to do that, it should do so by local means. > I think this is a reasonable arguement but it is a little too strong to say it is meaningless to the CE. For me, it has meaning to backup CEs because I have apps connected to the backup CEs. In hot standby mode, such apps receive any events they subscribed to. These events come from the FE. If i read you correctly: What you are asking is basically I worry at the master CE level of synchronizing to other CEs when instantiate/destroy happens via master CE. I believe this could be done - but it is a lot cheaper for such an event to come from the FE. cheers, jamal > Yours, > Joel > > > On 2/5/14, 6:43 AM, Jamal Hadi Salim wrote: >> >> Joel, >> I havent thought of the rare case you mention - but it would be taken care >> here >> as well. The scenario i described is not related to multiple CEs, >> rather multiple >> apps. >> In our implementation: >> We may have multiple applications talking to one or more CEs. >> The monitor example would be such an app which is passive, but other >> apps(eg a CLI) may be actively instantiating/destroying LFBs. >> In the case of multiple controllers, only the master of a specific CE is >> allowed >> to do writes to that FE. So apps will have to go via this sync point. >> >> cheers, >> jamal >> >> >> cheers, >> jamal >> >> >> >> >> On Tue, Feb 4, 2014 at 4:33 PM, Joel wrote: >>> >>> There seem to be two sub-cases of this, one of which is rare, and the >>> other >>> of which seems irrelevant. >>> >>> There is the rare case of the FE creating LFB instances on its own. This >>> is >>> legal, and arguably an event to detect this would be useful. But I can >>> not >>> imagine this is what you are looking for. >>> >>> >>> The other possibility is that your monitor is distinct from the CE, and >>> you >>> want to know about CE creation and deletion of the LFB instances. The >>> only >>> problem with taht is that by architecture we currently don't have >>> provision >>> for interacting with multiple CEs. If there is itnerest from I2RS we may >>> need to address that gap, but without addressing that I don't see how >>> something can be subscribed to FE events about CE actions. >>> >>> Yours, >>> Joel >>> >>> On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote: >>>> >>>> >>>> I feel need for Model extension to introduce Events for >>>> FEO LFB class instantiation and destruction. >>>> >>>> My use case - I wrote a simple monitor app. It does the following: >>>> >>>> a) subscribe to listen to FEs associating and disassociating >>>> b) When an FE associates to the controller, probe it for all >>>> all LFBs it supports and what versions >>>> c) subscribe to events on LFB instances of interest >>>> >>>> At this point we have state for FE + LFB instances stored within >>>> the App. We get events and in the simple case we just log them >>>> (but think of refreshing a GUI etc). >>>> My problem: >>>> I have no way of asynchronously knowing if an LFB instance >>>> to which i am subscribed-to for events is destroyed. Or a new one >>>> is instantiated so i can subscribe-to events should i need to. >>>> >>>> This event will help alleviate that pain. >>>> >>>> cheers, >>>> jamal >>>> _______________________________________________ >>>> forces mailing list >>>> forces@ietf.org >>>> https://www.ietf.org/mailman/listinfo/forces >>>> >>> > From hadi@mojatatu.com Sun Feb 9 07:31:02 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAAF1A03BD for ; Sun, 9 Feb 2014 07:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqd914clQXI8 for ; Sun, 9 Feb 2014 07:31:00 -0800 (PST) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id B37051A06DD for ; Sun, 9 Feb 2014 07:31:00 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id jx11so4209215veb.38 for ; Sun, 09 Feb 2014 07:31:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=jFN6Xi+gI+R6esl48jXiknMMKm7hnTsZ3ZWw1wbsycc=; b=IsWoCCweeJXSDg0zRPsB4VYpVOt0fEqdsQB4ljtRRNejagnFot//2kAYJw4aky1Gaf mXfvQvjp8Sm4F1em5eLhYx6+jph4TeRliQi3S3wBw26fESWeEjnw9giSwTMiFDQVBkVO Dy+Z+egEj8R3igBdhJ8dsFQ0aY4qwpwhP1a9yVxFH3rwW6SKxIyJVatXwlF6gSTFc8lS PNLAnqm2e1AKJjwOsLrlFIDSW5iWb7z7XO65J1rNt8x0uIyVdOwkR42eD7jH+4YzHZQZ lk0yMhztcD8ANIvvw6TprIamTblmcEQ8u89zye0+vs2tLBPo6wYPZ85OCz+uPeNnaTlc BMpA== X-Gm-Message-State: ALoCoQlNx+T8kWd3jNjC+V3vQVxk1dlcy+5woznAVANj/674ClWZ/BjFWxPcyDImd5LZZQwupHCd X-Received: by 10.52.117.115 with SMTP id kd19mr16398804vdb.15.1391959860703; Sun, 09 Feb 2014 07:31:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Sun, 9 Feb 2014 07:30:40 -0800 (PST) From: Jamal Hadi Salim Date: Sun, 9 Feb 2014 10:30:40 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] No meeting at IETF 89 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 15:31:02 -0000 Folks, We wont have a formal meeting at the upcoming IETF. There will be a side meeting between the chairs and document authors. If you want to talk about ForCES in this IETF meeting just send me an email and i will gladly meet. WG status ======== 1) I believe we are done with the previous charter as soon as the CEHA document is signed off by one of the authors. Expect RSN RFC 7121 to close that chapter. 2) Model extensions: draft-ietf-forces-model-extension-01 It seems ready. I had some last minute requests i wanted in there based on implementation experience. Based on discussions on the list I believe we need personal discussion. I plan to sit down with Evangelos and Joel - and we can hopefully close this. 3) Protocol extensions: draft-ietf-forces-protoextension-00 By mistake (as author), I republished draft-jhs-forces-protoextenstion-02 but will transfer the material to draft-ietf-forces-protoextension-01 after IETF 89. I think it seems ready. 4) subsidiary management A preliminary draft 00 should be out before this coming meeting. 5) Inter-FE draft: draft-joachimpillai-forces-interfelfb-03 This document is still not a WG document. I believe there may be more changes coming based on implementation experience and further feedback. 6) Parallelization of LFBs The document from Evangelos and Joel is becoming a WG document. Expect to see draft-ietf-forces-packet-parallelization-00 (I am awaiting DJ to accept it since i am having problems with my IETF web access) >From a general perspective: We are behind our schedule by at least 4 months. Keeping track of the timelines helps us focus. We should be able to catchup after requesting for publication of the protocol and model extensions. cheers, jamal From hadi@mojatatu.com Mon Feb 10 15:16:33 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D729E1A06D0 for ; Mon, 10 Feb 2014 15:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBrQ9yhshk7v for ; Mon, 10 Feb 2014 15:16:31 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5540A1A068E for ; Mon, 10 Feb 2014 15:16:31 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz11so5441741veb.4 for ; Mon, 10 Feb 2014 15:16:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=hkWyI80o97Of1pu/DjYtbqWcLR84R4d37wwDrq7ZD5g=; b=YDY04fITzXTnVXIxikKJdv7Dk/U4nRZBykajcqK3XIztlgyciwl/CB817pmjNomF4Y 9Wf8fJLgin49YI+aIzcUKF8I2zG9Dtgem3nKhh2kEWhO3pV61qEfc6GiIcEpzePCaRgJ 6ZBQCKHdwQ58NRuMkA4K3rjoBHqK6pJh89R4i41U0XcJ5WNzwC27pGT4u1mPgAvBgnxS tQkdefhcMPDc4RIScW/8kB0eY8EPubORNZ0Kpr8SQhGrMFxAtyH9rs8HuXaVRwpxnLe+ yrA5P+eDmP7E2k2yI9Joqiuz7fpnW9zL0aY1TaIlC6I0t1H7tmISu35DGyHxNsfr5C6D qBXw== X-Gm-Message-State: ALoCoQlou9296/jgYgHHLGcm4fqDP7Y53ui2mLg9hk/ThKwNTYQAHAdsDd0W7V8cfvicgHUXhQHY X-Received: by 10.220.145.5 with SMTP id b5mr20224697vcv.9.1392074190827; Mon, 10 Feb 2014 15:16:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Mon, 10 Feb 2014 15:16:10 -0800 (PST) In-Reply-To: <20140210155900.5892.57025.idtracker@ietfa.amsl.com> References: <20140210155900.5892.57025.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Mon, 10 Feb 2014 18:16:10 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] Fwd: New Version Notification for draft-khs-forces-lfb-subsidiary-management-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:16:34 -0000 A very preliminary version ---------- Forwarded message ---------- From: Date: Mon, Feb 10, 2014 at 10:59 AM Subject: New Version Notification for draft-khs-forces-lfb-subsidiary-management-00.txt To: Evangelos Haleplidis , Jamal Hadi Salim , Bhumip Khasnabish A new version of I-D, draft-khs-forces-lfb-subsidiary-management-00.txt has been successfully submitted by Evangelos Haleplidis and posted to the IETF repository. Name: draft-khs-forces-lfb-subsidiary-management Revision: 00 Title: IETF ForCES Logical Function Block (LFB) Subsidiary Management Document date: 2014-02-10 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-khs-forces-lfb-subsidiary-management-00.txt Status: https://datatracker.ietf.org/doc/draft-khs-forces-lfb-subsidiary-management/ Htmlized: http://tools.ietf.org/html/draft-khs-forces-lfb-subsidiary-management-00 Abstract: This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Forwarding Element (FE). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From wwwrun@rfc-editor.org Tue Feb 11 13:56:39 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9108A1A0798; Tue, 11 Feb 2014 13:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AVelMUPKUR2; Tue, 11 Feb 2014 13:56:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id EB64D1A079B; Tue, 11 Feb 2014 13:56:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 784107FC3AC; Tue, 11 Feb 2014 13:56:35 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140211215635.784107FC3AC@rfc-editor.org> Date: Tue, 11 Feb 2014 13:56:35 -0800 (PST) Cc: drafts-update-ref@iana.org, forces@ietf.org, rfc-editor@rfc-editor.org Subject: [forces] RFC 7121 on High Availability within a Forwarding and Control Element Separation (ForCES) Network Element X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:56:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7121 Title: High Availability within a Forwarding and Control Element Separation (ForCES) Network Element Author: K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim Status: Standards Track Stream: IETF Date: February 2014 Mailbox: k.ogawa@ntt.com, wmwang@mail.zjgsu.edu.cn, ehalep@ece.upatras.gr, hadi@mojatatu.com Pages: 31 Characters: 62599 Updates: RFC 5810 I-D Tag: draft-ietf-forces-ceha-10.txt URL: http://www.rfc-editor.org/rfc/rfc7121.txt This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hadi@mojatatu.com Wed Feb 12 05:45:46 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941C41A0307 for ; Wed, 12 Feb 2014 05:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmxSioCPxqT3 for ; Wed, 12 Feb 2014 05:45:44 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 500A21A00EE for ; Wed, 12 Feb 2014 05:45:44 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id g10so7010159vbg.14 for ; Wed, 12 Feb 2014 05:45:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Px0j89AP6TnIaGaGg+NU4XRaA5LnrPBwt9Ux8tRICqM=; b=c7qE+Sgj3tffhollaGE97fwpuZVDCVM/5PLjpi0R4GjTg8MUPSgOnIGichvcqWFsdo M//EtvuA4jR2E4s96ANTHoVGVg4WbB6xdFUcRROXOc1BmcN7escHv6mqUsMq9Kc/tyS0 OLrUf7wcZvkrX71TiwaR+0W/UB6JBQ8WfmkJD5haYzsIpv7kmlgU8F5w4VEBUXDo5fva 9omcnrM2gw7pEOts01bqYLMOiCbinEpOoOkjqxhxn6oCw+Me3+Ndd1WUHq6nwhXXInjb 9ShNRfDzg0USFofwx0EqhpZ65YmkqWBA+DaBSh5lBHnizymWM8SRmI8Bs36fOm82l98e nOPw== X-Gm-Message-State: ALoCoQnMSjV/7s86FAr9M0XI+YkIlMsLTTtSHLHV6IR0NHFaqfwQrYMRbCMmmz06ofMtgnagTLnn X-Received: by 10.220.252.134 with SMTP id mw6mr70632vcb.51.1392212743301; Wed, 12 Feb 2014 05:45:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Wed, 12 Feb 2014 05:45:23 -0800 (PST) In-Reply-To: <20140211215635.784107FC3AC@rfc-editor.org> References: <20140211215635.784107FC3AC@rfc-editor.org> From: Jamal Hadi Salim Date: Wed, 12 Feb 2014 08:45:23 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] Fwd: RFC 7121 on High Availability within a Forwarding and Control Element Separation (ForCES) Network Element X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 13:45:46 -0000 Folks, In case someone didnt pay attention - this is the end of a chapter. With this publication, we can now claim the previous charter is done ;-> cheers, jamal ---------- Forwarded message ---------- From: Date: Tue, Feb 11, 2014 at 4:56 PM Subject: [forces] RFC 7121 on High Availability within a Forwarding and Control Element Separation (ForCES) Network Element To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, forces@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7121 Title: High Availability within a Forwarding and Control Element Separation (ForCES) Network Element Author: K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim Status: Standards Track Stream: IETF Date: February 2014 Mailbox: k.ogawa@ntt.com, wmwang@mail.zjgsu.edu.cn, ehalep@ece.upatras.gr, hadi@mojatatu.com Pages: 31 Characters: 62599 Updates: RFC 5810 I-D Tag: draft-ietf-forces-ceha-10.txt URL: http://www.rfc-editor.org/rfc/rfc7121.txt This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From nobody Sat Feb 15 07:58:37 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103691A00F2; Sat, 15 Feb 2014 07:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlhCxSEURZbw; Sat, 15 Feb 2014 07:58:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB721A00EA; Sat, 15 Feb 2014 07:58:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140215155830.29138.95898.idtracker@ietfa.amsl.com> Date: Sat, 15 Feb 2014 07:58:30 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ybi_5LM0C6GmLPCoZZ88-_Hudrw Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-packet-parallelization-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 15:58:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Packet Parallelization Authors : Evangelos Haleplidis Joel Halpern Filename : draft-ietf-forces-packet-parallelization-00.txt Pages : 25 Date : 2014-02-05 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. Many network devices support parallel packet processing. This document describes how ForCES can model a network device's parallelization datapath. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-packet-parallelization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-packet-parallelization-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 25 04:04:00 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BC61A06C2 for ; Tue, 25 Feb 2014 04:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPQ5-gNbX3eB for ; Tue, 25 Feb 2014 04:03:56 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6BF1A06BC for ; Tue, 25 Feb 2014 04:03:56 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so287787veb.8 for ; Tue, 25 Feb 2014 04:03:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Kga17b2/RTCcFEU02Pg5G5R9yjQz5BKXuZJxmWI45iQ=; b=j9irPB4GXwNexK05/3WnhJGO/JweeUxqYTOd5XIJ6ldIceJMsLqqT4pOHF52GTFHPd uk9D/QnMZ0ukNtCJ/5S/nnouR8UNZtpI2TqOLxGiNMY0dRCeNptMf9utxsb9AnLQ3Lwb ER49Id9xdbXhlW3/4bDdLV6uaonGnSXxEhCQxCc8dZVQRgDgCMWV6bLNlmnWci0RHsXQ Y7Bh0ClQ+T9ok6RSNnDVMU5bPQ9Jn7WU4xzda8ll4pckloMNxAPKG8XxcUNwcCiHdzQE eN3qnR2tsGRFvaKjMDVkol3s/t50603pIi0ImKzOF068+ap0A6inxyYQppqfHlf+Xtb5 0BoQ== X-Gm-Message-State: ALoCoQlqruM2+3CnNLQnrHsm0awwU9S+sO+kZZL5a/CCFuT02xSjvnAhZidu7PZ0OhVfOmJf1dVj X-Received: by 10.52.89.230 with SMTP id br6mr712523vdb.20.1393329835409; Tue, 25 Feb 2014 04:03:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 25 Feb 2014 04:03:35 -0800 (PST) From: Jamal Hadi Salim Date: Tue, 25 Feb 2014 07:03:35 -0500 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Gar4ok-Rib8YFw1HsGKm8LZos7U Subject: [forces] LFB class Inheritance X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:03:58 -0000 We've run into a small (accidental) problem while using inheritance when someone changed a derived from structure in the parent LFB. 5812 section 3.2.8 says when specifying inheritance of an LFB class, that i need to specify not only the derived-from parent LFB class but also the version of the parent I am inheriting. The schema doesnt let me - what am i missing? cheers, jamal From nobody Tue Feb 25 09:23:11 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023C91A01E2 for ; Tue, 25 Feb 2014 09:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.929 X-Spam-Level: * X-Spam-Status: No, score=1.929 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQGUp-e5v5vK for ; Tue, 25 Feb 2014 09:23:04 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id C31671A0111 for ; Tue, 25 Feb 2014 09:23:04 -0800 (PST) Received: from dummy.name; Tue, 25 Feb 2014 17:23:03 +0000 Message-ID: <530CD178.8000101@stevecrocker.com> Date: Tue, 25 Feb 2014 12:23:04 -0500 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jamal Hadi Salim , "forces@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/fgd1GAjww1fIRUIC8XzlAKlnOYg Subject: Re: [forces] LFB class Inheritance X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:23:08 -0000 I think this is a case where we found ourselves with a problem. Specifying the version number for the base is awkward, and often likely to be unneeded. However, leaving it out creates the potential for collision, and thus failure. (Image base class Av1 uses IDs 1-10. class Bv1 is derived from A, and uses IDs 11 and 12. Now we do a new version of A, and Av2 uses ID 11. B can not be derived from Av2.) We appear to have simply dropped the ball on this. (Note to self: use issue trackers so as not to lose track of this sort of thing while revising documents.) Yours, Joel On 2/25/14, 7:03 AM, Jamal Hadi Salim wrote: > We've run into a small (accidental) problem while using inheritance when > someone changed a derived from structure in the parent LFB. > > 5812 section 3.2.8 says when specifying inheritance of an LFB class, > that i need to specify not only the derived-from parent LFB class but > also the version of the parent I am inheriting. > The schema doesnt let me - what am i missing? > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From nobody Tue Feb 25 09:48:58 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBC81A0105 for ; Tue, 25 Feb 2014 09:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ6ZvmJhyMs0 for ; Tue, 25 Feb 2014 09:48:46 -0800 (PST) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC181A0108 for ; Tue, 25 Feb 2014 09:48:46 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e49so1895033eek.34 for ; Tue, 25 Feb 2014 09:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=dSbwMb0Gt87YtWGp02VwAax+UgKFV1vACXpj5CdNLag=; b=dGA+Ie1cymSqh6mni/PSCsVarvNcrUAnVG0UZnKXMs9IC3cvAcUQBFcLJii6IWexEu MTCobQ6K31KYD0zdRl1DtTlXO8eELEX7NLeaDqgcdz4wN/+qp0/NXKtb5A5/elrEVkXV vmgSFhRez1O/SyOsEpKKYDuMpcm1+AECXR+8p0q9pKeJ44b6n09J/D5ZQUTV+ANRhMBX CDLL96B96f2lqJ6MhyGm0Ot0SQLAiH/tgDWUXoHL7mKf5mnC599y7X6YZUh4mKD6NePT +ddKXoaCnNN1W879W0mcwknL2d/Yq2+V1t+aeyF25y1JAhFZQth3g2bYk/R+Z8mEXxbY uLXQ== X-Received: by 10.14.29.6 with SMTP id h6mr1251183eea.84.1393350524954; Tue, 25 Feb 2014 09:48:44 -0800 (PST) Received: from EhalepXPS ([150.146.27.85]) by mx.google.com with ESMTPSA id j42sm79089409eep.21.2014.02.25.09.48.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 25 Feb 2014 09:48:44 -0800 (PST) From: "Haleplidis Evangelos" To: "'Joel'" , "'Jamal Hadi Salim'" , References: <530CD178.8000101@stevecrocker.com> In-Reply-To: <530CD178.8000101@stevecrocker.com> Date: Tue, 25 Feb 2014 19:48:43 +0200 Message-ID: <00c601cf3251$d3f6f270$7be4d750$@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: Ac8yTkOZZKgGrwT5Tb2q2m5AWJQ7WgAAof2w Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/SyZWdWXmyQjZ7VPMDtxZiQh6zQ8 Subject: Re: [forces] LFB class Inheritance X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:48:52 -0000 Greetings Jamal and Joel, I agree with Joel that there are potential collision issues and thus the version has to be included. I think we can easily address this issue within the model extension draft. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces [mailto:forces-bounces@ietf.org] On Behalf Of Joel > Sent: Tuesday, February 25, 2014 7:23 PM > To: Jamal Hadi Salim; forces@ietf.org > Subject: Re: [forces] LFB class Inheritance > > I think this is a case where we found ourselves with a problem. > Specifying the version number for the base is awkward, and often likely > to be unneeded. > > However, leaving it out creates the potential for collision, and thus > failure. (Image base class Av1 uses IDs 1-10. class Bv1 is derived > from A, and uses IDs 11 and 12. Now we do a new version of A, and Av2 > uses ID 11. B can not be derived from Av2.) > > We appear to have simply dropped the ball on this. (Note to self: use > issue trackers so as not to lose track of this sort of thing while > revising documents.) > > Yours, > Joel > > On 2/25/14, 7:03 AM, Jamal Hadi Salim wrote: > > We've run into a small (accidental) problem while using inheritance > > when someone changed a derived from structure in the parent LFB. > > > > 5812 section 3.2.8 says when specifying inheritance of an LFB class, > > that i need to specify not only the derived-from parent LFB class but > > also the version of the parent I am inheriting. > > The schema doesnt let me - what am i missing? > > > > 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 nobody Wed Feb 26 03:30:12 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123181A0252 for ; Wed, 26 Feb 2014 03:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPaK5I6WX3Ob for ; Wed, 26 Feb 2014 03:30:03 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 918E31A0057 for ; Wed, 26 Feb 2014 03:30:03 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so765597vcb.41 for ; Wed, 26 Feb 2014 03:30:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JTMg/QUs4Z89orxQSrZHyJYpbHb0kXNpjQVoEoZwjMw=; b=OSWkUNWL4cwf75xGqKZ2iAHr/mnHL340t4CKBgjd48DG6hYF/hHGNPAA5YN6Ux1zgs WZm+J+6FU+0SehbFt9iCHaEH7A16ijVEDlO7iSQnUqvfVE4tOXU5cf3X/aIIKC2y2eU+ zPEXhTNd7KVts/V4LS1E3BTqGeKz1dSNiIq3U2o0F/+9pjzY1cX62T1DqWZhwqq31PZs ZP++It3F0K/jEP0cuBWSMgqmJ+ouJTHJUrYOfKJidazIrUpyePWPIiey2CNtwTzRhT87 k8o71orOz7sI/PGgILmfwiOU4k+0Rp/v0qFfVCZHrT+Sin8KksAASsZYf9gPw+NI/BsR T8qQ== X-Gm-Message-State: ALoCoQlSP6VMPMsfuIuT1H0fewFzogXCVg/V9D5YlY7PV055VSLloYykFvAp8DzKSo5sFyKo/Mun X-Received: by 10.52.188.41 with SMTP id fx9mr4664278vdc.19.1393414202288; Wed, 26 Feb 2014 03:30:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Wed, 26 Feb 2014 03:29:42 -0800 (PST) In-Reply-To: <530CD178.8000101@stevecrocker.com> References: <530CD178.8000101@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 26 Feb 2014 06:29:42 -0500 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ZbTqSrPEhgjeusS3uaJHd7hASIs Cc: "forces@ietf.org" Subject: Re: [forces] LFB class Inheritance X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:30:08 -0000 On Tue, Feb 25, 2014 at 12:23 PM, Joel wrote: > I think this is a case where we found ourselves with a problem. > Specifying the version number for the base is awkward, and often likely to > be unneeded. > > However, leaving it out creates the potential for collision, and thus > failure. (Image base class Av1 uses IDs 1-10. class Bv1 is derived from A, > and uses IDs 11 and 12. Now we do a new version of A, and Av2 uses ID 11. > B can not be derived from Av2.) > Precisely the problem we ran into;-> Our compiler assumed we were overriding ID 11 from the newly minted Av2 (hence my earlier comment the discovery was "accidental"). > We appear to have simply dropped the ball on this. (Note to self: use issue > trackers so as not to lose track of this sort of thing while revising > documents.) > Would the suggestion from Evangelos to introduce this in the new model extensions suffice or do we still need an issue tracker entry? cheers, jamal > Yours, > Joel > > > On 2/25/14, 7:03 AM, Jamal Hadi Salim wrote: >> >> We've run into a small (accidental) problem while using inheritance when >> someone changed a derived from structure in the parent LFB. >> >> 5812 section 3.2.8 says when specifying inheritance of an LFB class, >> that i need to specify not only the derived-from parent LFB class but >> also the version of the parent I am inheriting. >> The schema doesnt let me - what am i missing? >> >> cheers, >> jamal >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > From nobody Wed Feb 26 05:46:46 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A507E1A0349 for ; Wed, 26 Feb 2014 05:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raPI536gHnSc for ; Wed, 26 Feb 2014 05:46:32 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 642BC1A0320 for ; Wed, 26 Feb 2014 05:46:32 -0800 (PST) Received: from dummy.name; Wed, 26 Feb 2014 13:46:30 +0000 Message-ID: <530DF035.6040903@stevecrocker.com> Date: Wed, 26 Feb 2014 08:46:29 -0500 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jamal Hadi Salim References: <530CD178.8000101@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/gmWACudPkG_8J8SRem8xSCfAPYg Cc: "forces@ietf.org" Subject: Re: [forces] LFB class Inheritance X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:46:33 -0000 For this issue, covering it in the model extensions draft is the right answer. The issue tracker point was more general (and broader than ForCES.) We have an issue tracker with the WG. We could use it to record this sort of issue. And then check it to make sure we actually dealt with all the issues. Yours, Joel On 2/26/14, 6:29 AM, Jamal Hadi Salim wrote: > On Tue, Feb 25, 2014 at 12:23 PM, Joel wrote: >> I think this is a case where we found ourselves with a problem. >> Specifying the version number for the base is awkward, and often likely to >> be unneeded. >> >> However, leaving it out creates the potential for collision, and thus >> failure. (Image base class Av1 uses IDs 1-10. class Bv1 is derived from A, >> and uses IDs 11 and 12. Now we do a new version of A, and Av2 uses ID 11. >> B can not be derived from Av2.) >> > > Precisely the problem we ran into;-> Our compiler assumed we were > overriding ID 11 > from the newly minted Av2 (hence my earlier comment the discovery was > "accidental"). > >> We appear to have simply dropped the ball on this. (Note to self: use issue >> trackers so as not to lose track of this sort of thing while revising >> documents.) >> > > Would the suggestion from Evangelos to introduce this in the new model > extensions suffice > or do we still need an issue tracker entry? > > cheers, > jamal > > >> Yours, >> Joel >> >> >> On 2/25/14, 7:03 AM, Jamal Hadi Salim wrote: >>> >>> We've run into a small (accidental) problem while using inheritance when >>> someone changed a derived from structure in the parent LFB. >>> >>> 5812 section 3.2.8 says when specifying inheritance of an LFB class, >>> that i need to specify not only the derived-from parent LFB class but >>> also the version of the parent I am inheriting. >>> The schema doesnt let me - what am i missing? >>> >>> cheers, >>> jamal >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> >>