From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 1 18:14:06 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14773 for ; Wed, 1 Jan 2003 18:14:04 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0085F068@cherry.ease.lsoft.com>; Wed, 1 Jan 2003 18:17:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32016085 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 1 Jan 2003 18:17:12 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 1 Jan 2003 18:17:12 -0500 Received: from localhost (hadi@localhost) by znyx.com (8.9.3/8.9.3) with ESMTP id PAA21205; Wed, 1 Jan 2003 15:30:23 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Message-ID: Date: Wed, 1 Jan 2003 15:30:23 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Subject: model draft comments Comments: cc: lily.l.yang@intel.com, jmh@joelhalpern.com, ram.gopal@nokia.com, ram.dantu@utdallas.edu To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Folks, I finally read or more like attempted to read but couldnt get myself to really focus on completely digesting the draft. I see this draft as attempts to be too many things at once without addressing clearly what i see as the real issues. I was tempted to write an alternative point of view, but realize we may not be that much different in the perspective of looking at this. So heres the way i see it: - I believe there are two layers to the modelling and your draft doesnt make a clear distinction between the two and hence the chaos. 1) A functional block layer: A functional block provides a mechanism for packet massaging. It must be told how to treat packets that traverse it. Typical modelling of a functional block would involve a table of sorts. The rows would represent states of _instances_ of the functional block. 2) A datapath layer: This is a graph/serialization of _instances_ of functional blocks as defined in a _policy_. Figure 6 in the draft is a good represantation the two. There are several instances of meters for example (representing layer 1 above) and a policy is used to interconnect them. In my opinion, this is sufficient representation. To digress: the ForCES protocol tells the individual functional blocks what to do (i.e it populates their tables with appropriate parameters). The CE maintains the datapath layer and its synchronization and would send a series of ForCEs messages (perhaps one to each functional block or to a group of blocks in the instantiated datapath/policy) to create a policy. What is being referenced in the draft is more akin to a CE point of view than an FE one - although thats not how it is potrayed. In order to help in laying out and managing the policy, the details that help are: a) capabilities: "this FE can handle IPv4 and IPv6 forwarding" b) Capacity "This FE has 8192 IPv4 table forwarding rows per port" These i believe are important elements of the model and maybe sufficient to express it. I am not sure if b) is that important for modeling really. The last item which seems to be an obsession with the draft is: datapath flow i.e how the fucntional blocks are laid out; in other words, what i refer to as policy. I think this adds a lot of complexity in the equation. If you factor it out to a CE concern (as opposed to it being an FE concern as in the draft) then it may be useful. Whether you believe or like it or not, implementors tend to use the model draft. In my opinion there should be no restrictions on how functional blocks are laid out. Lets leave that to the admin and whatever smarts the CE has to dissalow certain graphs of functional blocks (this may be useful for certain legacy devices). In more flexible devices - allow the admin/operator to shoot themselves if they wanted to (example use a combination that may not make any sense). This is the essence of good design/architectures (Look at how much the C language or unix allows in terms of policies). There are also a few implementation specific obscenities in the draft but i wont go into details because we seem to differ in the basics and we need to talk about that first. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 6 14:01:06 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10549 for ; Mon, 6 Jan 2003 14:01:05 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.008690B4@cherry.ease.lsoft.com>; Mon, 6 Jan 2003 14:04:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32265242 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jan 2003 14:04:19 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 6 Jan 2003 14:04:19 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id F3A081F0054; Mon, 6 Jan 2003 14:04:18 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 6F0151F0006; Mon, 6 Jan 2003 14:04:18 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E19D332.14879758@idt.com> Date: Mon, 6 Jan 2003 14:04:18 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments Comments: To: Jamal Hadi To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jamal Hadi wrote: > > - I believe there are two layers to the modelling and your draft doesnt > make a clear distinction between the two and hence the chaos. > > 1) A functional block layer: > A functional block provides a mechanism for packet massaging. > It must be told how to treat packets that traverse it. I agree. > 2) A datapath layer: > This is a graph/serialization of _instances_ of functional blocks as > defined in a _policy_. I agree. Note that it's possible to define, address, and manage functional blocks, completely independently of their interconnections (graph topology.) In addition, doing topology discover and configuration is an *extremely* difficult task. Page 5 of the draft, near the bottom, has the text: "However, the CE cannot reconfigure the graph topology dynamically, such as adding another meter or queue onto the FE in Figure 6 on the fly." To me, this would indicate that it's probably not necessary for the CE to know the topology. That is, if your "configuration" and "control" of something is limited to knowing it exists, then it you might as well treat it as if it didn't exist. > To digress: the ForCES protocol tells the individual functional blocks > what to do (i.e it populates their tables with appropriate parameters). > The CE maintains the datapath layer and its synchronization and would > send a series of ForCEs messages (perhaps one to each functional block > or to a group of blocks in the instantiated datapath/policy) to create a > policy. What is being referenced in the draft is more akin to a CE point > of view than an FE one - although thats not how it is potrayed. It's a conceptual view of how ForCES would fit into a larger environment. It needs details (or agreement on details) of the kind "ForCES applies here, but not there." Topology should probably be out of scope of ForCES, at least for the initial design and implementation. > The last item which seems to be an obsession with the draft is: > datapath flow i.e how the fucntional blocks are laid out; in other words, > what i refer to as policy. .. and the draft refers to as "graph topology" > I think this adds a lot of complexity in the equation. If you factor it > out to a CE concern (as opposed to it being an FE concern as in the > draft) then it may be useful. Whether you believe or like it or not, > implementors tend to use the model draft. I believe that those issues need to be discussed in the draft, if only to show how functional blocks fit into a larger application. > In my opinion there should be no restrictions on how functional blocks are > laid out. Lets leave that to the admin and whatever smarts the CE has > to dissalow certain graphs of functional blocks (this may be useful for > certain legacy devices). I agree. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 7 08:39:02 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12705 for ; Tue, 7 Jan 2003 08:39:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0086B309@cherry.ease.lsoft.com>; Tue, 7 Jan 2003 8:42:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32318661 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jan 2003 08:41:43 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 7 Jan 2003 08:31:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11924; Tue, 7 Jan 2003 08:28:25 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200301071328.IAA11924@ietf.org> Date: Tue, 7 Jan 2003 08:28:25 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-framework-04.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart 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 : Forwarding and Control Element Separation (ForCES) Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-04.txt Pages : 25 Date : 2003-1-6 This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and the interaction among them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-framework-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 7 11:09:57 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19350 for ; Tue, 7 Jan 2003 11:09:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0086B7F1@cherry.ease.lsoft.com>; Tue, 7 Jan 2003 11:13:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32333711 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jan 2003 11:13:03 -0500 Received: from 4.19.224.197 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 7 Jan 2003 11:03:02 -0500 Received: (from root@localhost) by mailscan.telica.com (8.11.6/8.11.6) id h07G31r32124; Tue, 7 Jan 2003 11:03:01 -0500 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by mailscan.telica.com (8.11.6/8.11.6) with SMTP id h07EuCt28374 for ; Tue, 7 Jan 2003 09:56:12 -0500 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18VtwQ-0004yA-00 for ietf-announce-list@ran.ietf.org; Tue, 07 Jan 2003 08:38:50 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18VtuL-0004vS-00 for all-ietf@ran.ietf.org; Tue, 07 Jan 2003 08:36:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11924; Tue, 7 Jan 2003 08:28:25 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Precedence: bulk Approved-By: owner-ietf-announce@IETF.ORG Message-ID: <200301071328.IAA11924@ietf.org> Date: Tue, 7 Jan 2003 08:28:25 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-framework-04.txt Comments: To: wkwan@telica.com To: FORCES@PEACH.EASE.LSOFT.COM --NextPart Title : Forwarding and Control Element Separation (ForCES) Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-04.txt Pages : 25 Date : 2003-1-6 (Forwarding and Control Element Separation) network elements, and identifies the associated entities and the interaction among them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-04.txt ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-framework-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 8 12:48:13 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28468 for ; Wed, 8 Jan 2003 12:48:10 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0086E771@cherry.ease.lsoft.com>; Wed, 8 Jan 2003 12:51:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32430419 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Jan 2003 12:51:24 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 8 Jan 2003 12:51:23 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4120766 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 08 Jan 2003 12:51:21 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030108124158.01808e60@mail.stevecrocker.com> Date: Wed, 8 Jan 2003 12:50:53 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3E19D332.14879758@idt.com> Precedence: list We have a basic choice about where on the spectrum of CE / FE controllability we wish to be. We could declare that the component graph is strictly under the control of the FE, and the CE has no say in it. If we say that, we will still need a way for the CE to understand the graph, but we we will be restricted in the services a CE can enable by the graph that actually exists on the FE. We could declare that the CE must be able to change the component graph in any way it wants to. This would allow any service in principle. In practice, this would be impossible, as no FE will allow every possible configuration of any possible number of graph elements. Thus, it seems (and has seemed) to me that we need to allow the CE to discover and manipulate the graph. There are limitations on that graph manipulation (and on the element manipulations) which can readily be communicated (in capabilities for example) so that the CE will generally know what it can and cannot do. There will be limitations on the graph and element manipulations which will not be captured in the capabilities, and will result in the CE receiving errors when it attempts some service establishments. As far as I can tell, while we can adjust where in this middle ground we are (and we should try for a good balance between power and simplicity in the point we select), we must operate in this middle ground. Yours, Joel M. Halpern At 02:04 PM 1/6/2003 -0500, Alan DeKok wrote: >Jamal Hadi wrote: > > > > - I believe there are two layers to the modelling and your draft doesnt > > make a clear distinction between the two and hence the chaos. > > > > 1) A functional block layer: > > A functional block provides a mechanism for packet massaging. > > It must be told how to treat packets that traverse it. > > I agree. > > > 2) A datapath layer: > > This is a graph/serialization of _instances_ of functional blocks as > > defined in a _policy_. > > I agree. Note that it's possible to define, address, and manage >functional blocks, completely independently of their interconnections >(graph topology.) In addition, doing topology discover and >configuration is an *extremely* difficult task. > > Page 5 of the draft, near the bottom, has the text: > > "However, the CE cannot reconfigure the graph topology > dynamically, such as adding another meter or queue onto > the FE in Figure 6 on the fly." > > To me, this would indicate that it's probably not necessary for the CE >to know the topology. That is, if your "configuration" and "control" of >something is limited to knowing it exists, then it you might as well >treat it as if it didn't exist. > > > To digress: the ForCES protocol tells the individual functional blocks > > what to do (i.e it populates their tables with appropriate parameters). > > The CE maintains the datapath layer and its synchronization and would > > send a series of ForCEs messages (perhaps one to each functional block > > or to a group of blocks in the instantiated datapath/policy) to create a > > policy. What is being referenced in the draft is more akin to a CE point > > of view than an FE one - although thats not how it is potrayed. > > It's a conceptual view of how ForCES would fit into a larger >environment. It needs details (or agreement on details) of the kind >"ForCES applies here, but not there." > > Topology should probably be out of scope of ForCES, at least for the >initial design and implementation. > > > The last item which seems to be an obsession with the draft is: > > datapath flow i.e how the fucntional blocks are laid out; in other words, > > what i refer to as policy. > > .. and the draft refers to as "graph topology" > > > I think this adds a lot of complexity in the equation. If you factor it > > out to a CE concern (as opposed to it being an FE concern as in the > > draft) then it may be useful. Whether you believe or like it or not, > > implementors tend to use the model draft. > > I believe that those issues need to be discussed in the draft, if only >to show how functional blocks fit into a larger application. > > > In my opinion there should be no restrictions on how functional blocks are > > laid out. Lets leave that to the admin and whatever smarts the CE has > > to dissalow certain graphs of functional blocks (this may be useful for > > certain legacy devices). > > I agree. > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 8 13:33:45 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01135 for ; Wed, 8 Jan 2003 13:33:44 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0086E8E1@cherry.ease.lsoft.com>; Wed, 8 Jan 2003 13:37:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32433212 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Jan 2003 13:37:00 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 8 Jan 2003 13:36:59 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 74F271F0064 for ; Wed, 8 Jan 2003 13:36:59 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 2AE281F0062 for ; Wed, 8 Jan 2003 13:36:59 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20030108124158.01808e60@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E1C6FCB.CE670FD0@idt.com> Date: Wed, 8 Jan 2003 13:36:59 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > > We have a basic choice about where on the spectrum of CE / FE > controllability we wish to be. My opinion is that we can avoid much of this discussion by agreeing on elements which are common across the spectrum, or models. e.g. Addressing a particular component of the graph is independent of how the graph is represented, and who represents it. The CE could simply be told "here's a collection of handles to components", and can often manage those components without knowing their relationships. > We could declare that the component graph is strictly under the control of > the FE, and the CE has no say in it. If we say that, we will still need a > way for the CE to understand the graph, I agree it would be useful for the CE to understand the graph, but I'm not sure it's required. I would like to have diagrams and examples of the various scenarios to put the discussion on a concrete setting. Until then, the discussion is too vague to enable us to move forwards. > but we we will be restricted in the > services a CE can enable by the graph that actually exists on the FE. > We could declare that the CE must be able to change the component graph in > any way it wants to. This would allow any service in principle. In > practice, this would be impossible, as no FE will allow every possible > configuration of any possible number of graph elements. And the connections between the graph elements are often static, and defined by physical traces on a board. > Thus, it seems (and has seemed) to me that we need to allow the CE to > discover and manipulate the graph. There are limitations on that graph > manipulation (and on the element manipulations) which can readily be > communicated (in capabilities for example) so that the CE will generally > know what it can and cannot do. There will be limitations on the graph and > element manipulations which will not be captured in the capabilities, and > will result in the CE receiving errors when it attempts some service > establishments. I agree. We now have some interesting questions. 1. How do we represent the graph? 2. Where is that graph representation stored at boot time? 3. How is that information communicated to the elements which need it? e.g. Systems with PCI busses can do PCI queries, and have a well-defined way of discovering any graph topology at boot time. Application-layer changes aren't required. Do we want systems supporting ForCES to have a similar discovery protocol? How do we address the graph components? How do we communicate component capabilities? Graph topology is a difficult area to work with. I'd like to see those issues seperated from the component configuration and control, which is where I see ForCES being applied. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 9 09:49:54 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13060 for ; Thu, 9 Jan 2003 09:49:53 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008709D8@cherry.ease.lsoft.com>; Thu, 9 Jan 2003 9:53:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32503588 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jan 2003 09:53:08 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 9 Jan 2003 09:53:08 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h09ESk0g024113; Thu, 9 Jan 2003 06:28:46 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.2] References: <5.1.0.14.0.20030108124158.01808e60@mail.stevecrocker.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Approved-By: Jamal Hadi Salim Message-ID: <03010817522200.00784@jzny> Date: Wed, 8 Jan 2003 17:52:22 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030108124158.01808e60@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 8bit On Wednesday 08 January 2003 12:50, Joel M. Halpern wrote: > We have a basic choice about where on the spectrum of CE / FE > controllability we wish to be. > We could declare that the component graph is strictly under the control of > the FE, and the CE has no say in it. If we say that, we will still need a > way for the CE to understand the graph, but we we will be restricted in the > services a CE can enable by the graph that actually exists on the FE. The FE should really only own the component/node/element and its config. It should be able to refuse a config for a node - but thats as far as it should go if it should stay simple. Policy control should not be under the FEs domain (rather owned by the CE). > We could declare that the CE must be able to change the component graph in > any way it wants to. This would allow any service in principle. In > practice, this would be impossible, as no FE will allow every possible > configuration of any possible number of graph elements. > The graph layouts aka policy being owned by the CE is a very good start i.e the CE sees the big picture. You can embed the intelligence in the CE to decide what the possible configuration of the graph elements are. You can also embed the intelligence of what possible per-element configs are in the CE (either after youve discovered them or by virtue of them being well known). The graph element should be able to reject specific configs (in which case the graph instance is incomplete). > Thus, it seems (and has seemed) to me that we need to allow the CE to > discover and manipulate the graph. There are limitations on that graph > manipulation (and on the element manipulations) which can readily be > communicated (in capabilities for example) so that the CE will generally > know what it can and cannot do. Discovery of element manipulations is a well known science. Discovery of the possibilities of graph configurations adds a second dimension to the challenge and is a hard problem .. This is what Alan was saying and i agree with him. protocols like COPS tried to resolve this but in my opinion are insufficient and very limiting (that is why it is so hard to add new extensions to COPS). Forgeting "legacy" devices for a sec - i think a free hand in policy description is the way to go. Give someone a gun and let them shoot themsleves. If you wanna put restrictions put them in the CE in the form of ACLs - make it part of the configuration. > There will be limitations on the graph and > element manipulations which will not be captured in the capabilities, and > will result in the CE receiving errors when it attempts some service > establishments. > yes, thats a fallback - but i only see that for element config. For graph config, packets going to never land is your fault. > As far as I can tell, while we can adjust where in this middle ground we > are (and we should try for a good balance between power and simplicity in > the point we select), we must operate in this middle ground. > My opinion of the role of the two dimensions (element vs graph manipulation) is pretty clear. what do you conmsider a middle ground? cheers, jamal > Yours, > Joel M. Halpern > > At 02:04 PM 1/6/2003 -0500, Alan DeKok wrote: > >Jamal Hadi wrote: > > > - I believe there are two layers to the modelling and your draft doesnt > > > make a clear distinction between the two and hence the chaos. > > > > > > 1) A functional block layer: > > > A functional block provides a mechanism for packet massaging. > > > It must be told how to treat packets that traverse it. > > > > I agree. > > > > > 2) A datapath layer: > > > This is a graph/serialization of _instances_ of functional blocks as > > > defined in a _policy_. > > > > I agree. Note that it's possible to define, address, and manage > >functional blocks, completely independently of their interconnections > >(graph topology.) In addition, doing topology discover and > >configuration is an *extremely* difficult task. > > > > Page 5 of the draft, near the bottom, has the text: > > > > "However, the CE cannot reconfigure the graph topology > > dynamically, such as adding another meter or queue onto > > the FE in Figure 6 on the fly." > > > > To me, this would indicate that it's probably not necessary for the CE > >to know the topology. That is, if your "configuration" and "control" of > >something is limited to knowing it exists, then it you might as well > >treat it as if it didn't exist. > > > > > To digress: the ForCES protocol tells the individual functional blocks > > > what to do (i.e it populates their tables with appropriate parameters). > > > The CE maintains the datapath layer and its synchronization and would > > > send a series of ForCEs messages (perhaps one to each functional block > > > or to a group of blocks in the instantiated datapath/policy) to create > > > a policy. What is being referenced in the draft is more akin to a CE > > > point of view than an FE one - although thats not how it is potrayed. > > > > It's a conceptual view of how ForCES would fit into a larger > >environment. It needs details (or agreement on details) of the kind > >"ForCES applies here, but not there." > > > > Topology should probably be out of scope of ForCES, at least for the > >initial design and implementation. > > > > > The last item which seems to be an obsession with the draft is: > > > datapath flow i.e how the fucntional blocks are laid out; in other > > > words, what i refer to as policy. > > > > .. and the draft refers to as "graph topology" > > > > > I think this adds a lot of complexity in the equation. If you factor it > > > out to a CE concern (as opposed to it being an FE concern as in the > > > draft) then it may be useful. Whether you believe or like it or not, > > > implementors tend to use the model draft. > > > > I believe that those issues need to be discussed in the draft, if only > >to show how functional blocks fit into a larger application. > > > > > In my opinion there should be no restrictions on how functional blocks > > > are laid out. Lets leave that to the admin and whatever smarts the CE > > > has to dissalow certain graphs of functional blocks (this may be useful > > > for certain legacy devices). > > > > I agree. > > > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 9 17:20:10 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28268 for ; Thu, 9 Jan 2003 17:20:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00871ADD@cherry.ease.lsoft.com>; Thu, 9 Jan 2003 17:23:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32534470 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jan 2003 17:23:05 -0500 Received: from 205.188.157.42 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 9 Jan 2003 17:23:05 -0500 Received: from Aaudu2000@aol.com by imo-d10.mx.aol.com (mail_out_v34.13.) id a.29.35acd47e (15888) for ; Thu, 9 Jan 2003 17:21:26 -0500 (EST) Received: from aol.com (mow-d17.webmail.aol.com [205.188.139.133]) by air-id08.mx.aol.com (v90.10) with ESMTP id MAILINID83-0109172126; Thu, 09 Jan 2003 17:21:26 -0500 MIME-Version: 1.0 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: Aaudu2000@AOL.COM Message-ID: <56B8DCE5.2A0F356B.0218F5DE@aol.com> Date: Thu, 9 Jan 2003 17:21:26 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi Alan, The information conveyed by the "graph" is pretty important for it determines the beahvior of the FE in relation to the overall NE. I am assuming the "graph" in this sense represents the relative placements (or location in the data path) of the resources in the FE. Making such placements configurable (by CE or otherwise) will allow bahvioral modifcation or programmability of the NE. This is a good thing. The extent of that programmabiility however depends on advances in chip technology of which FEs are made. But logically, this shouldn't be too difficult to do. It will probably be useful to come up with a set of graphs of those resources, and then provide a documented mapping between each graph and the corresponding FE behavior. rfc 3290 is a useful starting point towards this goal. To answer your questions: 1. How do we represent the graph? We can possibly assign unique IDs to the resources or components. Once that is done, stringing then up in a sort of linked list to reflect the graph becomes easy. 2. Where is that graph representation stored at boot time? In the case where resource graphs are preset (most restrictive), graphs could be stored in non-volatile memory of some sort. However, assuming programmability, the FEs will probably boot up with unconfigured graphs. It is up to CE to configure the graphs based on intended beahviors for the FEs. In this case, the graph will be stored in RAM,..which could then be saved off into a more persistent storage if need be. 3. How is that information communicated to the elements which need it? This will be domain of the inter FE and CE protocol (e.g. FACT). Cheers, Alex. In a message dated 1/8/2003 1:36:59 PM Eastern Standard Time, Alan DeKok writes: >"Joel M. Halpern" wrote: >> >> We have a basic choice about where on the spectrum of CE / FE >> controllability we wish to be. > > My opinion is that we can avoid much of this discussion by agreeing on >elements which are common across the spectrum, or models. > > e.g. Addressing a particular component of the graph is independent of >how the graph is represented, and who represents it. The CE could >simply be told "here's a collection of handles to components", and can >often manage those components without knowing their relationships. > >> We could declare that the component graph is strictly under the control of >> the FE, and the CE has no say in it. If we say that, we will still need a >> way for the CE to understand the graph, > > I agree it would be useful for the CE to understand the graph, but I'm >not sure it's required. I would like to have diagrams and examples of >the various scenarios to put the discussion on a concrete setting. >Until then, the discussion is too vague to enable us to move forwards. > >> but we we will be restricted in the >> services a CE can enable by the graph that actually exists on the FE. >> We could declare that the CE must be able to change the component graph in >> any way it wants to. This would allow any service in principle. In >> practice, this would be impossible, as no FE will allow every possible >> configuration of any possible number of graph elements. > > And the connections between the graph elements are often static, and >defined by physical traces on a board. > >> Thus, it seems (and has seemed) to me that we need to allow the CE to >> discover and manipulate the graph. There are limitations on that graph >> manipulation (and on the element manipulations) which can readily be >> communicated (in capabilities for example) so that the CE will generally >> know what it can and cannot do. There will be limitations on the graph and >> element manipulations which will not be captured in the capabilities, and >> will result in the CE receiving errors when it attempts some service >> establishments. > > I agree. We now have some interesting questions. > >1. How do we represent the graph? >2. Where is that graph representation stored at boot time? >3. How is that information communicated to the elements which need it? > > e.g. Systems with PCI busses can do PCI queries, and have a >well-defined way of discovering any graph topology at boot time. >Application-layer changes aren't required. > > Do we want systems supporting ForCES to have a similar discovery >protocol? How do we address the graph components? How do we >communicate component capabilities? > > > Graph topology is a difficult area to work with. I'd like to see >those issues seperated from the component configuration and control, >which is where I see ForCES being applied. > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 10 10:18:54 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00366 for ; Fri, 10 Jan 2003 10:18:53 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00873791@cherry.ease.lsoft.com>; Fri, 10 Jan 2003 10:22:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32592600 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jan 2003 10:22:10 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 10 Jan 2003 10:22:09 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 5FD931F0053 for ; Fri, 10 Jan 2003 10:22:09 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 3B22A1F0004 for ; Fri, 10 Jan 2003 10:22:09 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <56B8DCE5.2A0F356B.0218F5DE@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E1EE520.5A4FA5EE@idt.com> Date: Fri, 10 Jan 2003 10:22:08 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alex Audu wrote: > > The information conveyed by the "graph" is pretty important for it > determines the beahvior > of the FE in relation to the overall NE. Sure, but the draft says it doesn't support reconfiguration or reconnection of the graph topology. So if it's static, then knowing the topology is much less important than if it could change. > I am assuming the "graph" in > this sense represents > the relative placements (or location in the data path) of the resources > in the FE. Making such > placements configurable (by CE or otherwise) will allow bahvioral > modifcation or programmability > of the NE. This is a good thing. It's also extremely difficult, which is why it's currently outside of the scope of ForCES. > To answer your questions: > 1. How do we represent the graph? > We can possibly assign unique IDs to the resources or components. > Once that is done, > stringing then up in a sort of linked list to reflect the graph > becomes easy. I disagree *completely*. I deal with graph topology and manipulation every day, and it's just not that easy. You can have 1-N, N-1, or N-M relationships between graph elements. You can have loops. You can have cross-connections. Linked lists are insufficient. Naive solutions are inadequate. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 10 13:20:31 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08595 for ; Fri, 10 Jan 2003 13:20:30 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0087489F@cherry.ease.lsoft.com>; Fri, 10 Jan 2003 13:23:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32600198 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jan 2003 13:23:44 -0500 Received: from 64.12.136.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 10 Jan 2003 13:23:44 -0500 Received: from Aaudu2000@aol.com by imo-m02.mx.aol.com (mail_out_v34.13.) id a.16a.18feaa36 (15875) for ; Fri, 10 Jan 2003 13:23:37 -0500 (EST) Received: from aol.com (mow-m21.webmail.aol.com [64.12.180.137]) by air-id07.mx.aol.com (v90.10) with ESMTP id MAILINID72-0110132337; Fri, 10 Jan 2003 13:23:37 -0500 MIME-Version: 1.0 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: Aaudu2000@AOL.COM Message-ID: <426971E8.1259CCE9.0218F5DE@aol.com> Date: Fri, 10 Jan 2003 13:23:37 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Alan, The current FE Model draft doesn't rule out "dynamic FE control and configuration". In fact, it plans to support it "to a certain degree when it makes sense". I suggest you read the "Capability Model versus State Model" section again. As for topology representation, surely, graph topology representation and manipulation could be quite complex, especially when you allow arbitrary transitions between nodes. Luckily, our problem domain is not that complex. So we need a constrained graph that maps nicely to our problem space. I mean, I don't see any reason to allow for loops in a data flow path in an network element. I suggest you look at the IEEE P1520 specs to get an insight as to how linked lists could be used to represent dynamically configurable data flow paths in a network element. Cheers, Alex. In a message dated 1/10/2003 10:22:08 AM Eastern Standard Time, Alan DeKok writes: >Alex Audu wrote: >> >> The information conveyed by the "graph" is pretty important for it >> determines the beahvior >> of the FE in relation to the overall NE. > > Sure, but the draft says it doesn't support reconfiguration or >reconnection of the graph topology. So if it's static, then knowing the >topology is much less important than if it could change. > >> I am assuming the "graph" in >> this sense represents >> the relative placements (or location in the data path) of the resources >> in the FE. Making such >> placements configurable (by CE or otherwise) will allow bahvioral >> modifcation or programmability >> of the NE. This is a good thing. > > It's also extremely difficult, which is why it's currently outside of >the scope of ForCES. > >> To answer your questions: >> 1. How do we represent the graph? >> We can possibly assign unique IDs to the resources or components. >> Once that is done, >> stringing then up in a sort of linked list to reflect the graph >> becomes easy. > > I disagree *completely*. I deal with graph topology and manipulation >every day, and it's just not that easy. You can have 1-N, N-1, or N-M >relationships between graph elements. You can have loops. You can have >cross-connections. > > Linked lists are insufficient. Naive solutions are inadequate. > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 10 14:06:34 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12577 for ; Fri, 10 Jan 2003 14:06:33 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00874F85@cherry.ease.lsoft.com>; Fri, 10 Jan 2003 14:09:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32601765 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jan 2003 14:09:49 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 10 Jan 2003 14:09:49 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 2666B1F0053 for ; Fri, 10 Jan 2003 14:09:49 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id E0F781F0004 for ; Fri, 10 Jan 2003 14:09:48 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <426971E8.1259CCE9.0218F5DE@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E1F1A7A.B3698398@idt.com> Date: Fri, 10 Jan 2003 14:09:46 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alex Audu wrote: > > Alan, > > The current FE Model draft doesn't rule out "dynamic FE control and configuration". In fact, it plans to support it I've never disagreed with that. > "to a certain degree when it makes sense". > I suggest you read the "Capability Model versus State Model" > section again. I don't understand what the problem is. I think you've misunderstood my point. I will quote a line from the FE functional model draft, in the section you would have me re-read. I had previously quoted this section in my message of January 6, to the list. Near the bottom of page 5: "However, the CE cannot reconfigure the graph topology dynamically, such as adding another meter or queue onto the FE in figure 6 on the fly." This kind of graph topology reconfiguration is explicitely outside of the scope of ForCES. I agree with that limitation of the scope. > As for topology representation, surely, graph topology > representation and manipulation could be quite complex, especially when you allow arbitrary transitions between nodes. > Luckily, our problem domain is not that complex. I'm not sure that we can make that statement. > So we need > a constrained graph that maps nicely to our problem space. > I mean, I don't see any reason to allow for loops in a data flow path in an network element. There are logical loops and physical loops. The same NE may process a packet twice, and that ability should be shown in any graph which represents the FE. However, from the point of view of a packet, it simply transits a number of NE's, and probably doesn't know or care that some may be the same. > I suggest you look at the IEEE P1520 specs to get an insight > as to how linked lists could be used to represent dynamically > configurable data flow paths in a network element. Do you have a URL to a specific document? Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 10 17:57:14 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19194 for ; Fri, 10 Jan 2003 17:57:12 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00877174@cherry.ease.lsoft.com>; Fri, 10 Jan 2003 18:00:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32609713 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jan 2003 18:00:05 -0500 Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 10 Jan 2003 18:00:04 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0AMvWh13789 for ; Fri, 10 Jan 2003 22:57:32 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id h0ALvmO05683 for ; Fri, 10 Jan 2003 21:57:48 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011014004425952 for ; Fri, 10 Jan 2003 14:00:44 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 14:02:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Khosravi, Hormuzd M" Message-ID: Date: Fri, 10 Jan 2003 14:02:33 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Hi All, I agree with Alex. I think its basically essential to have knowledge about the functionality or capabilities of the FE in order to control/configure it. For example, if the FE has 2 functional blocks, an IPv4 block followed by a NAT block, its necessary to know the order in which these blocks are linked in order to configure them. For example, a NAT function may change a packet's source or destination IP address. Any number of other logical functions (e.g., layer 3 forwarding, ingress/egress firewall) may make use of the source or destination IP address when making decisions. The CE needs to know whether to configure these logical functions with the pre-NAT or post-NAT IP address. The Requirements draft speaks about importance of ordering in section 6.3 and the Model draft is basically following all the requirements. Another thing is that, I don't think this is complicated or adds complexity to the protocol. This information is inherently present on the FE and has to be conveyed to the CE, which could be done in a single protocol message... one way is described below by Alex. There are well known and easy to understand data structures that can be used to represent graphs, it is not a fundamentally hard problem. Thanks Hormuzd -----Original Message----- From: Alex Audu [mailto:Aaudu2000@aol.com] Sent: Thursday, January 09, 2003 2:21 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] model draft comments Hi Alan, The information conveyed by the "graph" is pretty important for it determines the beahvior of the FE in relation to the overall NE. I am assuming the "graph" in this sense represents the relative placements (or location in the data path) of the resources in the FE. Making such placements configurable (by CE or otherwise) will allow bahvioral modifcation or programmability of the NE. This is a good thing. The extent of that programmabiility however depends on advances in chip technology of which FEs are made. But logically, this shouldn't be too difficult to do. It will probably be useful to come up with a set of graphs of those resources, and then provide a documented mapping between each graph and the corresponding FE behavior. rfc 3290 is a useful starting point towards this goal. To answer your questions: 1. How do we represent the graph? We can possibly assign unique IDs to the resources or components. Once that is done, stringing then up in a sort of linked list to reflect the graph becomes easy. 2. Where is that graph representation stored at boot time? In the case where resource graphs are preset (most restrictive), graphs could be stored in non-volatile memory of some sort. However, assuming programmability, the FEs will probably boot up with unconfigured graphs. It is up to CE to configure the graphs based on intended beahviors for the FEs. In this case, the graph will be stored in RAM,..which could then be saved off into a more persistent storage if need be. 3. How is that information communicated to the elements which need it? This will be domain of the inter FE and CE protocol (e.g. FACT). Cheers, Alex. In a message dated 1/8/2003 1:36:59 PM Eastern Standard Time, Alan DeKok writes: >"Joel M. Halpern" wrote: >> >> We have a basic choice about where on the spectrum of CE / FE >> controllability we wish to be. > > My opinion is that we can avoid much of this discussion by agreeing on >elements which are common across the spectrum, or models. > > e.g. Addressing a particular component of the graph is independent of >how the graph is represented, and who represents it. The CE could >simply be told "here's a collection of handles to components", and can >often manage those components without knowing their relationships. > >> We could declare that the component graph is strictly under the control of >> the FE, and the CE has no say in it. If we say that, we will still need a >> way for the CE to understand the graph, > > I agree it would be useful for the CE to understand the graph, but I'm >not sure it's required. I would like to have diagrams and examples of >the various scenarios to put the discussion on a concrete setting. >Until then, the discussion is too vague to enable us to move forwards. > >> but we we will be restricted in the >> services a CE can enable by the graph that actually exists on the FE. >> We could declare that the CE must be able to change the component graph in >> any way it wants to. This would allow any service in principle. In >> practice, this would be impossible, as no FE will allow every possible >> configuration of any possible number of graph elements. > > And the connections between the graph elements are often static, and >defined by physical traces on a board. > >> Thus, it seems (and has seemed) to me that we need to allow the CE to >> discover and manipulate the graph. There are limitations on that graph >> manipulation (and on the element manipulations) which can readily be >> communicated (in capabilities for example) so that the CE will generally >> know what it can and cannot do. There will be limitations on the graph and >> element manipulations which will not be captured in the capabilities, and >> will result in the CE receiving errors when it attempts some service >> establishments. > > I agree. We now have some interesting questions. > >1. How do we represent the graph? >2. Where is that graph representation stored at boot time? >3. How is that information communicated to the elements which need it? > > e.g. Systems with PCI busses can do PCI queries, and have a >well-defined way of discovering any graph topology at boot time. >Application-layer changes aren't required. > > Do we want systems supporting ForCES to have a similar discovery >protocol? How do we address the graph components? How do we >communicate component capabilities? > > > Graph topology is a difficult area to work with. I'd like to see >those issues seperated from the component configuration and control, >which is where I see ForCES being applied. > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 13 14:29:35 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20998 for ; Mon, 13 Jan 2003 14:29:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0088AE4E@cherry.ease.lsoft.com>; Mon, 13 Jan 2003 14:32:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32729277 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jan 2003 12:02:19 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Jan 2003 12:02:19 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h0DGbG0g057421; Mon, 13 Jan 2003 08:37:17 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.2] References: <426971E8.1259CCE9.0218F5DE@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Approved-By: Jamal Hadi Salim Message-ID: <03011306101000.01148@jzny> Date: Mon, 13 Jan 2003 06:10:10 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments Comments: To: Alex Audu To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <426971E8.1259CCE9.0218F5DE@aol.com> Precedence: list Content-Transfer-Encoding: 8bit On Friday 10 January 2003 13:23, Alex Audu wrote: > Alan, > > The current FE Model draft doesn't rule out "dynamic FE control and > configuration". In fact, it plans to support it "to a certain degree when > it makes sense". > I suggest you read the "Capability Model versus State Model" > section again. > Lets not even go there first. We need to resolove a very simple question under discussion at the moment. > As for topology representation, surely, graph topology > representation and manipulation could be quite complex, especially when you > allow arbitrary transitions between nodes. Luckily, our problem domain is > not that complex. So we need > a constrained graph that maps nicely to our problem space. > I mean, I don't see any reason to allow for loops in a data flow path in an > network element. > This should be left to the intelligence in the CE. I may want to allow loops. > I suggest you look at the IEEE P1520 specs to get an insight You mean a marketing insight? Please let sleeping horses lie. On Friday 10 January 2003 17:02, Khosravi, Hormuzd M wrote: > Hi All, > > I agree with Alex. I think its basically essential to have knowledge about > the functionality or capabilities of the FE in order to control/configure > it sure - btw, dont think anybody disagreed with this. > For example, if the FE has 2 functional blocks, an IPv4 block followed > by a NAT block, its necessary to know the order in which these blocks are > linked in order to configure them. For example, a NAT function may change > a packet's source or destination IP address. Any number of other logical > functions (e.g., layer 3 forwarding, ingress/egress firewall) may make use > of the source or destination IP address when making decisions. The CE > needs > > to know whether to configure these logical functions with the pre-NAT or > post-NAT IP address. The Requirements draft speaks about importance of > ordering > in section 6.3 and the Model draft is basically following all the > requirements. > the contention point is whether that ordering belongs in the FE block or whether it belongs in the policy which builds a collection of blocks. As far as the NAT block is concerned, and i hate to use obscene words, but if you design it right, it doesnt have to know whether it is doing pre or post NAT activity. Ordering is a policy requirement. And no graphing of these blocks is not a simple thing unless you are talking about simplistic models like the one below or the one used by COPS. cheers, jamal > as to how linked lists could be used to represent dynamically > configurable data flow paths in a network element > > Cheers, > Alex. > > In a message dated 1/10/2003 10:22:08 AM Eastern Standard Time, Alan DeKok writes: > >Alex Audu wrote: > >> The information conveyed by the "graph" is pretty important for it > >> determines the beahvior > >> of the FE in relation to the overall NE. > > > > Sure, but the draft says it doesn't support reconfiguration or > >reconnection of the graph topology. So if it's static, then knowing the > >topology is much less important than if it could change. > > > >> I am assuming the "graph" in > >> this sense represents > >> the relative placements (or location in the data path) of the > >> resources in the FE. Making such > >> placements configurable (by CE or otherwise) will allow bahvioral > >> modifcation or programmability > >> of the NE. This is a good thing. > > > > It's also extremely difficult, which is why it's currently outside of > >the scope of ForCES. > > > >> To answer your questions: > >> 1. How do we represent the graph? > >> We can possibly assign unique IDs to the resources or components. > >> Once that is done, > >> stringing then up in a sort of linked list to reflect the graph > >> becomes easy. > > > > I disagree *completely*. I deal with graph topology and manipulation > >every day, and it's just not that easy. You can have 1-N, N-1, or N-M > >relationships between graph elements. You can have loops. You can have > >cross-connections. > > > > Linked lists are insufficient. Naive solutions are inadequate. > > > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 13 15:31:57 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23076 for ; Mon, 13 Jan 2003 15:31:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0088B74D@cherry.ease.lsoft.com>; Mon, 13 Jan 2003 15:35:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32739371 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jan 2003 14:45:33 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Jan 2003 14:45:33 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4138683 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jan 2003 14:45:32 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <426971E8.1259CCE9.0218F5DE@aol.com> <426971E8.1259CCE9.0218F5DE@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030113143844.02603968@mail.stevecrocker.com> Date: Mon, 13 Jan 2003 14:45:20 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03011306101000.01148@jzny> Precedence: list I must be misunderstanding your concern. No one is asking for a system where the CE can tell the FE to do something it is not capable of. No one is asking to mandate that all FEs have adjustable paths between components. But some FE do have such power. And allowing the control expressions to specify connectivity, given that the model has to already represent connectivity, conditionals (which packets which take which exit from a multi-exit block), and API semantics (what information is preserved across the interfaces between model blocks, does not seem to add complexity. I think I am missing something in your complexity assertion. The policy framework Qos Device Datapath Information Model is not simple. But it is not intractable either. The DIffServ framework model is somewhat simpler, and still quite powerful. Personally, I would guess that the logic in the standard for describing a sufficiently powerful forwarding table block (which is a single block) is going to be more difficult than the potential for graph manipulation. We do have to be careful. But it does not seem to be a show stopper. Yours, Joel M. Halpern At 06:10 AM 1/13/2003 -0500, Jamal Hadi Salim wrote: >And no graphing of these blocks is not a simple thing unless you are talking >about simplistic models like the one below or the one used by COPS. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 14 10:30:58 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27505 for ; Tue, 14 Jan 2003 10:30:57 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00890104@cherry.ease.lsoft.com>; Tue, 14 Jan 2003 10:34:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32821416 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Jan 2003 10:33:33 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Jan 2003 10:33:33 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h0EF8S0g065954 for ; Tue, 14 Jan 2003 07:08:28 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.2] References: <426971E8.1259CCE9.0218F5DE@aol.com> <5.1.0.14.0.20030113143844.02603968@mail.stevecrocker.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Approved-By: Jamal Hadi Salim Message-ID: <03011404412700.00889@jzny> Date: Tue, 14 Jan 2003 04:41:27 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030113143844.02603968@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 8bit On Monday 13 January 2003 14:45, Joel M. Halpern wrote: > I must be misunderstanding your concern. > > No one is asking for a system where the CE can tell the FE to do something > it is not capable of. No one is asking to mandate that all FEs have > adjustable paths between components. > But some FE do have such power. no arguement there. > And allowing the control expressions to specify connectivity, given that > the model has to already represent connectivity, conditionals (which > packets which take which exit from a multi-exit block), and API semantics > (what information is preserved across the interfaces between model blocks, > does not seem to add complexity. > By "control expressions to specify connectivity" i take it you mean "policy" or some layer above the configuration of a specific block. What needs to be defined in a model are the two layers. Do you think this is outside the scope of a model? > I think I am missing something in your complexity assertion. The policy > framework Qos Device Datapath Information Model is not simple. But it is > not intractable either. The DIffServ framework model is somewhat simpler, > and still quite powerful. > I am not arguing on intractability; however, i worry about statements like the one you make in equating this to a qos model (these assertions are made by a lot of other people ofcourse); the qos model is _simpler_ with well defined elements and a path in a graph (regardless of the multi-exit paths). The FE model in Forces MUST be able to express the above two models and a little MORE - hence my complexity assertion. In other words, you can reduce the Qos model to a forces model but not the other way round. > Personally, I would guess that the logic in the standard for describing a > sufficiently powerful forwarding table block (which is a single block) is > going to be more difficult than the potential for graph manipulation. We > do have to be careful. But it does not seem to be a show stopper. > I think they are equally complex. You can make the graph simpler by enforcing a set of functions and a fixed path at the expense of loosing valuable flexibility. I believe we should be able to make it both simple and and flexible and while i think the qos models have things to offer, they are a subset of the Forces FE problem domain. I apologize if i am sounding religious. cheers, jamal > Yours, > Joel M. Halpern > > At 06:10 AM 1/13/2003 -0500, Jamal Hadi Salim wrote: > >And no graphing of these blocks is not a simple thing unless you are > > talking about simplistic models like the one below or the one used by > > COPS. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 14 23:17:37 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21982 for ; Tue, 14 Jan 2003 23:17:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00891F7A@cherry.ease.lsoft.com>; Tue, 14 Jan 2003 23:20:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32884770 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Jan 2003 23:20:54 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Jan 2003 23:20:54 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0F4FPR04580 for ; Wed, 15 Jan 2003 04:15:25 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0F4G0000851 for ; Wed, 15 Jan 2003 04:16:00 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011420223410587 for ; Tue, 14 Jan 2003 20:22:34 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 20:20:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Approved-By: "Khosravi, Hormuzd M" Message-ID: Date: Tue, 14 Jan 2003 20:20:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Jamal, unfortunately i am unable to understand what your objection is ? you agree that the FE capabilities are imp and need to be expressed, but you dont want them to be expressed as a graph ?? you seem to contradict yourself or may be i am misunderstanding.... could you pls explain yourself may be by using some examples as to your objection and describing the complexity of this issue ? also, if you could explain what the simpler approach is using an example that would help. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: Monday, January 13, 2003 3:10 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] model draft comments On Friday 10 January 2003 13:23, Alex Audu wrote: > Alan, > > The current FE Model draft doesn't rule out "dynamic FE control and > configuration". In fact, it plans to support it "to a certain degree when > it makes sense". > I suggest you read the "Capability Model versus State Model" > section again. > Lets not even go there first. We need to resolove a very simple question under discussion at the moment. > As for topology representation, surely, graph topology > representation and manipulation could be quite complex, especially when you > allow arbitrary transitions between nodes. Luckily, our problem domain is > not that complex. So we need > a constrained graph that maps nicely to our problem space. > I mean, I don't see any reason to allow for loops in a data flow path in an > network element. > This should be left to the intelligence in the CE. I may want to allow loops. > I suggest you look at the IEEE P1520 specs to get an insight You mean a marketing insight? Please let sleeping horses lie. On Friday 10 January 2003 17:02, Khosravi, Hormuzd M wrote: > Hi All, > > I agree with Alex. I think its basically essential to have knowledge about > the functionality or capabilities of the FE in order to control/configure > it sure - btw, dont think anybody disagreed with this. > For example, if the FE has 2 functional blocks, an IPv4 block followed > by a NAT block, its necessary to know the order in which these blocks are > linked in order to configure them. For example, a NAT function may change > a packet's source or destination IP address. Any number of other logical > functions (e.g., layer 3 forwarding, ingress/egress firewall) may make use > of the source or destination IP address when making decisions. The CE > needs > > to know whether to configure these logical functions with the pre-NAT or > post-NAT IP address. The Requirements draft speaks about importance of > ordering > in section 6.3 and the Model draft is basically following all the > requirements. > the contention point is whether that ordering belongs in the FE block or whether it belongs in the policy which builds a collection of blocks. As far as the NAT block is concerned, and i hate to use obscene words, but if you design it right, it doesnt have to know whether it is doing pre or post NAT activity. Ordering is a policy requirement. And no graphing of these blocks is not a simple thing unless you are talking about simplistic models like the one below or the one used by COPS. cheers, jamal > as to how linked lists could be used to represent dynamically > configurable data flow paths in a network element > > Cheers, > Alex. > > In a message dated 1/10/2003 10:22:08 AM Eastern Standard Time, Alan DeKok writes: > >Alex Audu wrote: > >> The information conveyed by the "graph" is pretty important for it > >> determines the beahvior > >> of the FE in relation to the overall NE. > > > > Sure, but the draft says it doesn't support reconfiguration or > >reconnection of the graph topology. So if it's static, then knowing the > >topology is much less important than if it could change. > > > >> I am assuming the "graph" in > >> this sense represents > >> the relative placements (or location in the data path) of the > >> resources in the FE. Making such > >> placements configurable (by CE or otherwise) will allow bahvioral > >> modifcation or programmability > >> of the NE. This is a good thing. > > > > It's also extremely difficult, which is why it's currently outside of > >the scope of ForCES. > > > >> To answer your questions: > >> 1. How do we represent the graph? > >> We can possibly assign unique IDs to the resources or components. > >> Once that is done, > >> stringing then up in a sort of linked list to reflect the graph > >> becomes easy. > > > > I disagree *completely*. I deal with graph topology and manipulation > >every day, and it's just not that easy. You can have 1-N, N-1, or N-M > >relationships between graph elements. You can have loops. You can have > >cross-connections. > > > > Linked lists are insufficient. Naive solutions are inadequate. > > > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 15 10:56:52 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00901 for ; Wed, 15 Jan 2003 10:56:50 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0089300C@cherry.ease.lsoft.com>; Wed, 15 Jan 2003 11:00:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32916492 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jan 2003 11:00:10 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Jan 2003 11:00:10 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 84A0C1F007C for ; Wed, 15 Jan 2003 11:00:09 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id EC5D21F006A for ; Wed, 15 Jan 2003 11:00:08 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E258586.CB511E21@idt.com> Date: Wed, 15 Jan 2003 11:00:06 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Khosravi, Hormuzd M" wrote: > > unfortunately i am unable to understand what your objection is ? > you agree that the FE capabilities are imp and need to be expressed, > but you dont want them to be expressed as a graph ?? I'll reply with my understanding of the issues. 1. Once you have a known handle, addressing and configuring a particular NE element of an FE is relatively simple. 2. Representing trivial graphs is relatively simple. e.g. 'a->b, a->c, b->c' is a graph. 3. Representing the capabilities of the inter-element links is difficult. 4. Representing the topology reconfiguration limitations of the inter-element links is difficult. (e.g. can the link a->c be deleted?) 5. Having the CE *interpret* any graph is difficult. The question which comes from #5 is: How do you use a CE to convert a collection of FE's and NE's, with their topology, into a router with certain capabilities? The answer to that question is usually: Write an application which is dedicated to those elements, and to that topology. > you seem to contradict yourself or may be i am misunderstanding.... > could you pls explain yourself may be by using some examples as > to your objection and describing the complexity of this issue ? > also, if you could explain what the simpler approach is using an > example that would help. I'm inclined to ask the question the opposite way. Some people believe X is easy, others believe it's hard. I would say it's up to the people saying it's easy to demonstrate why. What we're talking about is a complex graph, with capabilities, functionalities, and/or code associated with both elements and transitions between elements. The CE we're trying to develop is capable of understanding the graph, the transitions, and the capabilities. The CE is capable of taking that understanding, and turning it into nearly any kind of network-aware device. Are there existing examples of this kind of capability and configuration? As I said, I think it's a *very* hard problem. For real-life examples, see lex, yacc, or www.ragel.ca. All of these take parse rules & associated code as input, and produce a state machine which is the end application "managing" the data. What I think we're talking about here is the ability to have both a lex-style "NE/FE grammar", and instead of C code for state transitions, have a "CE interpreter", which uses the grammar to build network devices. I can't see why anyone would view this as easy. Then again, I could be missing something. e.g. The diffserv functional model defines a well-known graph topology, with well-known behaviour. It should be easy to generalize the FE/NE's underlying a diffserv router, so that the CE can configure and control them without knowing vendor-specific details. I understand how that can be done in ForCES, without too much complexity. As Jamal said, I'm also unclear on how that model can be generalized to allow the CE to control *any* graph topology, with *any* network functionality. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 17 19:44:55 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08276 for ; Fri, 17 Jan 2003 19:44:53 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008996EC@cherry.ease.lsoft.com>; Fri, 17 Jan 2003 19:48:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33170325 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jan 2003 19:48:15 -0500 Received: from 143.182.124.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Jan 2003 19:48:14 -0500 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h0I0msM09163 for ; Sat, 18 Jan 2003 00:48:55 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011716461624864 for ; Fri, 17 Jan 2003 16:46:16 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 16:48:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Khosravi, Hormuzd M" Message-ID: Date: Fri, 17 Jan 2003 16:48:12 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Hi Alan Thanks for the detailed reply, its helpful to understand your view. I agree with a lot of things your saying below and I don't think that everything you have stated below (e.g. merging FE Caps from multiple FEs) needs to be done at the ForCES protocol level. However, the protocol should facilitate this, to be done by any app on the CE in a standard way. And the FE model is one way of expressing these caps. Is there any specific text in the draft which you think could be reworded or causes this understanding ? Pls point it out. Also, I have given more comments below. Thanks Hormuzd -----Original Message----- From: Alan DeKok [mailto:alan.dekok@idt.com] Sent: Wednesday, January 15, 2003 8:00 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] model draft comments "Khosravi, Hormuzd M" wrote: > > unfortunately i am unable to understand what your objection is ? > you agree that the FE capabilities are imp and need to be expressed, > but you dont want them to be expressed as a graph ?? I'll reply with my understanding of the issues. 1. Once you have a known handle, addressing and configuring a particular NE element of an FE is relatively simple. [HK] I agree 2. Representing trivial graphs is relatively simple. e.g. 'a->b, a->c, b->c' is a graph. [HK] Sure 3. Representing the capabilities of the inter-element links is difficult. [HK] Does the draft mention inter-element caps ? When you say inter-element, do you mean inter-FE or inter functional block? If the latter, why do they need capabilities? 4. Representing the topology reconfiguration limitations of the inter-element links is difficult. (e.g. can the link a->c be deleted?) 5. Having the CE *interpret* any graph is difficult. The question which comes from #5 is: How do you use a CE to convert a collection of FE's and NE's, with their topology, into a router with certain capabilities? [HK] I don't think merging capabilities from different FEs in a single graph is something that the ForCES protocol needs to do or contain logic for. However, the ForCES protocol would facilitate this by providing the CE with the FE Capabilities. Its up to the CE as to what it does with this information. The answer to that question is usually: Write an application which is dedicated to those elements, and to that topology. > you seem to contradict yourself or may be i am misunderstanding.... > could you pls explain yourself may be by using some examples as > to your objection and describing the complexity of this issue ? > also, if you could explain what the simpler approach is using an > example that would help. I'm inclined to ask the question the opposite way. Some people believe X is easy, others believe it's hard. I would say it's up to the people saying it's easy to demonstrate why. [HK]The model is a proposal as to how to do it. What we're talking about is a complex graph, with capabilities, functionalities, and/or code associated with both elements and transitions between elements. The CE we're trying to develop is capable of understanding the graph, the transitions, and the capabilities. The CE is capable of taking that understanding, and turning it into nearly any kind of network-aware device. Are there existing examples of this kind of capability and configuration? As I said, I think it's a *very* hard problem. For real-life examples, see lex, yacc, or www.ragel.ca. All of these take parse rules & associated code as input, and produce a state machine which is the end application "managing" the data. What I think we're talking about here is the ability to have both a lex-style "NE/FE grammar", and instead of C code for state transitions, have a "CE interpreter", which uses the grammar to build network devices. I can't see why anyone would view this as easy. Then again, I could be missing something. [HK] This seems like the most powerful, but also most complex, possible approach to building a CE. Why not start with a CE that recognizes the presence of certain fairly simple graphs and uses those? e.g. The diffserv functional model defines a well-known graph topology, with well-known behaviour. It should be easy to generalize the FE/NE's underlying a diffserv router, so that the CE can configure and control them without knowing vendor-specific details. I understand how that can be done in ForCES, without too much complexity. As Jamal said, I'm also unclear on how that model can be generalized to allow the CE to control *any* graph topology, with *any* network functionality. [HK] Sure, we can start by building a fairly dumb CE that can control common graphs and then extend it to more functions. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 20 10:34:25 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21969 for ; Mon, 20 Jan 2003 10:34:24 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0089D9B6@cherry.ease.lsoft.com>; Mon, 20 Jan 2003 10:37:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33296180 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Jan 2003 10:37:44 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Jan 2003 10:37:44 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h0KFE6Dp003620; Mon, 20 Jan 2003 07:14:07 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.2] References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Approved-By: Jamal Hadi Salim Message-ID: <03012004451904.00916@jzny> Date: Mon, 20 Jan 2003 04:45:19 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 8bit On Tuesday 14 January 2003 23:20, Khosravi, Hormuzd M wrote: > Jamal, > > unfortunately i am unable to understand what your objection is ? > you agree that the FE capabilities are imp and need to be expressed, > but you dont want them to be expressed as a graph ?? > you seem to contradict yourself or may be i am misunderstanding.... > could you pls explain yourself may be by using some examples as > to your objection and describing the complexity of this issue ? Please reread emails from both myself and Alan. There are some very fundamental issues that need to be addressed. It may require rewritting the whole draft - so no point in discussing pieces of text that could be reworded (and no point in repeating here, read the emails i or Alan sent). Unfortunately, the authors of the draft are probably too pre-occupied elsewhere - we need to hear from them as well. Else lets rename this working group as "ForCES for QoS and IPV4 forwarding". > also, if you could explain what the simpler approach is using an > example that would help. > Theres work in progress here which assumes : http://www.cyberus.ca/~hadi/patches/action unfortunately the docs are sparse and it is just that work in progress when i get bored (A lot more features havent been exposed yet) cheers, jamal > Thanks > Hormuzd > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Monday, January 13, 2003 3:10 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] model draft comments > > On Friday 10 January 2003 13:23, Alex Audu wrote: > > Alan, > > > > The current FE Model draft doesn't rule out "dynamic FE control and > > configuration". In fact, it plans to support it "to a certain degree when > > it makes sense". > > I suggest you read the "Capability Model versus State Model" > > section again. > > Lets not even go there first. We need to resolove a very simple question > under discussion at the moment. > > > As for topology representation, surely, graph topology > > representation and manipulation could be quite complex, especially when > > you > > > allow arbitrary transitions between nodes. Luckily, our problem domain is > > not that complex. So we need > > a constrained graph that maps nicely to our problem space. > > I mean, I don't see any reason to allow for loops in a data flow path in > > an > > > network element. > > This should be left to the intelligence in the CE. I may want to allow > loops. > > > I suggest you look at the IEEE P1520 specs to get an insight > > You mean a marketing insight? Please let sleeping horses lie. > > On Friday 10 January 2003 17:02, Khosravi, Hormuzd M wrote: > > Hi All, > > > > I agree with Alex. I think its basically essential to have knowledge > > about the functionality or capabilities of the FE in order to > > control/configure it > > sure - btw, dont think anybody disagreed with this. > > > For example, if the FE has 2 functional blocks, an IPv4 block followed > > by a NAT block, its necessary to know the order in which these blocks are > > linked in order to configure them. For example, a NAT function may change > > a packet's source or destination IP address. Any number of other logical > > functions (e.g., layer 3 forwarding, ingress/egress firewall) may make > > use of the source or destination IP address when making decisions. The > > CE needs > > > > to know whether to configure these logical functions with the pre-NAT or > > post-NAT IP address. The Requirements draft speaks about importance of > > ordering > > in section 6.3 and the Model draft is basically following all the > > requirements. > > the contention point is whether that ordering belongs in the FE block or > whether it belongs in the policy which builds a collection of blocks. > As far as the NAT block is concerned, and i hate to use obscene words, but > if > you design it right, it doesnt have to know whether it is doing pre or post > NAT activity. Ordering is a policy requirement. > > And no graphing of these blocks is not a simple thing unless you are > talking about simplistic models like the one below or the one used by COPS. > > cheers, > jamal > > > as to how linked lists could be used to represent dynamically > > configurable data flow paths in a network element > > > > > > Cheers, > > Alex. > > > > In a message dated 1/10/2003 10:22:08 AM Eastern Standard Time, Alan > > DeKok > > writes: > > >Alex Audu wrote: > > >> The information conveyed by the "graph" is pretty important for it > > >> determines the beahvior > > >> of the FE in relation to the overall NE. > > > > > > Sure, but the draft says it doesn't support reconfiguration or > > >reconnection of the graph topology. So if it's static, then knowing the > > >topology is much less important than if it could change. > > > > > >> I am assuming the "graph" in > > >> this sense represents > > >> the relative placements (or location in the data path) of the > > >> resources in the FE. Making such > > >> placements configurable (by CE or otherwise) will allow bahvioral > > >> modifcation or programmability > > >> of the NE. This is a good thing. > > > > > > It's also extremely difficult, which is why it's currently outside of > > >the scope of ForCES. > > > > > >> To answer your questions: > > >> 1. How do we represent the graph? > > >> We can possibly assign unique IDs to the resources or components. > > >> Once that is done, > > >> stringing then up in a sort of linked list to reflect the graph > > >> becomes easy. > > > > > > I disagree *completely*. I deal with graph topology and manipulation > > >every day, and it's just not that easy. You can have 1-N, N-1, or N-M > > >relationships between graph elements. You can have loops. You can have > > >cross-connections. > > > > > > Linked lists are insufficient. Naive solutions are inadequate. > > > > > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 20 13:35:41 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26698 for ; Mon, 20 Jan 2003 13:35:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0089E081@cherry.ease.lsoft.com>; Mon, 20 Jan 2003 13:39:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33306668 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Jan 2003 13:39:05 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Jan 2003 13:39:05 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id B71B21F005E for ; Mon, 20 Jan 2003 13:39:04 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 57ECF1F005B for ; Mon, 20 Jan 2003 13:39:04 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E2C4247.D99E3CAB@idt.com> Date: Mon, 20 Jan 2003 13:39:03 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Khosravi, Hormuzd M" wrote: > > Thanks for the detailed reply, its helpful to understand your view. > I agree with a lot of things your saying below and I don't think that > everything you have stated below (e.g. merging FE Caps from multiple > FEs) needs to be done at the ForCES protocol level. I agree. But a generic "understanding" CE like you propose will have to do that. If we don't know how to have the CE merge the FE capabilities to create a network device, then I don't see how a generic capability description is useful. > However, the protocol > should facilitate this, to be done by any app on the CE in a standard way. > And the FE model is one way of expressing these caps. Is there any specific > text in the draft which you think could be reworded or causes this > understanding ? My main is section 5, item 10. I agree that the FE's must provide topology information to the CE, but I'm unclear as to what kind of topology information is required. e.g. "This FE implements the DiffServ model" is a topology description, which would appear to satisfy the requirements. One topic of research, I think, is how much topology information is useful, and how we can use that information. If we decide that we don't know what to do with complex topologies & configurations, then there isn't much point in requiring the implementations to supply that information. > 3. Representing the capabilities of the inter-element links is > difficult. > [HK] Does the draft mention inter-element caps ? When you say inter-element, > do you mean inter-FE or inter functional block? If the latter, > why do they need capabilities? I mean inter-functional block capabilities. I believe that they *may* need capability descriptions, because different inter-element connections have different physical capabilities. Since those differences exist, we cannot create a complete functional model of the device without also modelling those capabilities. > The question which comes from #5 is: How do you use a CE to convert a > collection of FE's and NE's, with their topology, into a router with > certain capabilities? > > [HK] I don't think merging capabilities from different FEs in a single > graph is something that the ForCES protocol needs to do or contain logic > for. However, the ForCES protocol would facilitate this by providing > the CE with the FE Capabilities. Its up to the CE as to what it does with > this information. If we don't know how the CE would use this information, then I question the need for supplying it. > I'm inclined to ask the question the opposite way. Some people > believe X is easy, others believe it's hard. I would say it's up to the > people saying it's easy to demonstrate why. > > [HK]The model is a proposal as to how to do it. I believe that the model document is still incomplete, and that there are unsolved issues which it hasn't addresses. > [ lex, yacc, etc ] > > [HK] This seems like the most powerful, but also most complex, possible > approach to building a CE. Why not start with a CE that recognizes > the presence of certain fairly simple graphs and uses those? > > e.g. The diffserv functional model defines a well-known graph > topology, with well-known behaviour. It should be easy to generalize > the FE/NE's underlying a diffserv router, so that the CE can configure > and control them without knowing vendor-specific details. I agree completely. But that's for a well-known topology, where you know where certain elements are located, and *why*. > [HK] Sure, we can start by building a fairly dumb CE that can control > common graphs and then extend it to more functions. I doubt it's that easy. If it was, then we would be able to take a UML document describing the desired interaction of network devices, and run it through a "compiler", which would generate: - protocol description - protocol stack - conceptual model - applications We just can't do this. It took what, 2 years for the Diffserv group to come up with the information management model (RFC 3290). You're proposing that the CE has this capability for *any* network configuration, and *any* FE, and *any* network protocol? It's an astonishingly difficult problem. That's why we have working groups in the IETF. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 20 16:06:35 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00929 for ; Mon, 20 Jan 2003 16:06:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0089E586@cherry.ease.lsoft.com>; Mon, 20 Jan 2003 16:09:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33333201 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Jan 2003 16:09:58 -0500 Received: from 143.182.124.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Jan 2003 16:09:57 -0500 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h0KLAaQ14404 for ; Mon, 20 Jan 2003 21:10:36 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003012013075810345 for ; Mon, 20 Jan 2003 13:07:58 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Jan 2003 13:09:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Mon, 20 Jan 2003 13:09:50 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Framework draft status update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, This email is a note to the WG regarding the status of the ForCES Framework document. On Tuesday, November 5, a last call was initiated: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0211&L=forces&T=0&O=D&P=158 The last call completed on November 18, as documented in the ForCES IETF55 meeting minutes: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0212&L=forces&T=0&O=D&P=164 The authors received some comments, which where responded to by updating the framework document. The updated framework was uploaded on Tuesday, January 7: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0301&L=forces&T=0&O=D&P=229 http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-04.txt The changes where relatively minor. A diff is available: http://www.sstanamera.com/~forces/Old/Framework04to03.diff This document is being sent to our routing area advisor for review. Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 20 16:29:34 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01638 for ; Mon, 20 Jan 2003 16:29:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0089E65E@cherry.ease.lsoft.com>; Mon, 20 Jan 2003 16:32:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33333995 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Jan 2003 16:32:57 -0500 Received: from 209.202.115.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Jan 2003 16:32:57 -0500 Received: (qmail 7487 invoked from network); 20 Jan 2003 21:39:41 -0000 Received: (ofmipd 138.120.62.62); 20 Jan 2003 21:39:19 -0000 X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------924AC891402AB802D8531527" Approved-By: Milan Zoranovic Message-ID: <3E2C6B08.C749C95D@alcatel.com> Date: Mon, 20 Jan 2003 16:32:56 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Milan Zoranovic Organization: Alcatel Subject: Re: Framework draft status update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --------------924AC891402AB802D8531527 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello David, What happened with a Messaging FAPI Study Group Proposal at the last NPF? Regards, Milan "Putzolu, David" wrote: > All, > > This email is a note to the WG regarding the status of > the ForCES Framework document. > > On Tuesday, November 5, a last call was initiated: > http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0211&L=forces&T=0&O=D&P=158 > > The last call completed on November 18, as documented > in the ForCES IETF55 meeting minutes: > http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0212&L=forces&T=0&O=D&P=164 > > The authors received some comments, which where responded > to by updating the framework document. The updated framework > was uploaded on Tuesday, January 7: > http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0301&L=forces&T=0&O=D&P=229 > http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-04.txt > > The changes where relatively minor. A diff is available: > http://www.sstanamera.com/~forces/Old/Framework04to03.diff > > This document is being sent to our routing area advisor > for review. > > Cheers, > David -- Milan Zoranovic Datapath Research Engineer Alcatel Research & Innovation 600 March Rd. Ottawa, ON K2K 2E6 613-784-5994 --------------924AC891402AB802D8531527 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello David,

What happened with a Messaging FAPI Study Group Proposal at the last NPF?

Regards,

Milan

"Putzolu, David" wrote:

All,

This email is a note to the WG regarding the status of
the ForCES Framework document.

On Tuesday, November 5, a last call was initiated:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0211&L=forces&T=0&O=D&P=158

The last call completed on November 18, as documented
in the ForCES IETF55 meeting minutes:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0212&L=forces&T=0&O=D&P=164

The authors received some comments, which where responded
to by updating the framework document. The updated framework
was uploaded on Tuesday, January 7:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0301&L=forces&T=0&O=D&P=229
http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-04.txt

The changes where relatively minor. A diff is available:
http://www.sstanamera.com/~forces/Old/Framework04to03.diff

This document is being sent to our routing area advisor
for review.

Cheers,
David

--
Milan Zoranovic
Datapath Research Engineer
Alcatel Research & Innovation
600 March Rd.
Ottawa, ON  K2K 2E6
613-784-5994
  --------------924AC891402AB802D8531527-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 00:32:38 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11863 for ; Tue, 21 Jan 2003 00:32:37 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0089FB7B@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 0:36:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33382626 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 00:36:00 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 00:36:00 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0L5UO212165 for ; Tue, 21 Jan 2003 05:30:24 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0L5V1N00143 for ; Tue, 21 Jan 2003 05:31:01 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003012021374828061 for ; Mon, 20 Jan 2003 21:37:48 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Jan 2003 21:35:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Approved-By: "Khosravi, Hormuzd M" Message-ID: Date: Mon, 20 Jan 2003 21:35:56 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Hi Alan, One clarification before I reply, I was looking at model-01 draft and section 5 does not have item 10. do you mean section 4.3.2 ? Thanks Hormuzd -----Original Message----- From: Alan DeKok [mailto:alan.dekok@idt.com] Sent: Monday, January 20, 2003 10:39 AM > However, the protocol > should facilitate this, to be done by any app on the CE in a standard way. > And the FE model is one way of expressing these caps. Is there any specific > text in the draft which you think could be reworded or causes this > understanding ? My main is section 5, item 10. I agree that the FE's must provide topology information to the CE, but I'm unclear as to what kind of topology information is required. e.g. "This FE implements the DiffServ model" is a topology description, which would appear to satisfy the requirements. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 09:45:26 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01395 for ; Tue, 21 Jan 2003 09:45:25 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.008A0571@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 9:48:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33399948 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 09:48:51 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 09:48:50 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id C926B1F0066 for ; Tue, 21 Jan 2003 09:48:50 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 9E35E1F0059 for ; Tue, 21 Jan 2003 09:48:50 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E2D5DD2.C5235DD4@idt.com> Date: Tue, 21 Jan 2003 09:48:50 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Khosravi, Hormuzd M" wrote: > > One clarification before I reply, I was looking at model-01 draft > and section 5 does not have item 10. do you mean section 4.3.2 ? Sorry. I meant the requirements document, section 5, item 10. My comments were not that the requirments document had to be revised, but that the model document should make it clear how it will satisfy those requirements. Simply saying "we represent a graph topology and the CE interprets it" is insufficient for me to understand how it's supposed to work. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 09:58:00 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01648 for ; Tue, 21 Jan 2003 09:57:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.008A056F@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 10:01:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33400341 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 10:01:11 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 10:01:11 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h0LEbPDp011916 for ; Tue, 21 Jan 2003 06:37:26 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.2] References: <3E2D5DD2.C5235DD4@idt.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Approved-By: Jamal Hadi Salim Message-ID: <03012104084401.00998@jzny> Date: Tue, 21 Jan 2003 04:08:44 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3E2D5DD2.C5235DD4@idt.com> Precedence: list Content-Transfer-Encoding: 8bit Why is Hormuzd doing all the responding on behalf of the model draft's authors? Occasionaly Joel appears, you pose a question to him then he disappears. I think we should kill the current model draft and start a new one perhaps with new authors. I honestly see no point in discussing it at all if the authors dont bother to participate. cheers, jamal On Tuesday 21 January 2003 09:48, Alan DeKok wrote: > "Khosravi, Hormuzd M" wrote: > > One clarification before I reply, I was looking at model-01 draft > > and section 5 does not have item 10. do you mean section 4.3.2 ? > > Sorry. I meant the requirements document, section 5, item 10. > > My comments were not that the requirments document had to be revised, > but that the model document should make it clear how it will satisfy > those requirements. Simply saying "we represent a graph topology and > the CE interprets it" is insufficient for me to understand how it's > supposed to work. > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 10:32:12 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02583 for ; Tue, 21 Jan 2003 10:32:10 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008A05E7@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 10:35:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33402293 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 10:35:32 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 10:35:31 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LFblt09830 for ; Tue, 21 Jan 2003 17:37:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 17:35:30 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 17:35:29 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 07:35:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: model draft comments Thread-Index: AcLBXgFAktlGhk1eQkqUX+IgrWCqvQAAsTaA X-OriginalArrivalTime: 21 Jan 2003 15:35:26.0534 (UTC) FILETIME=[B873AE60:01C2C162] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Tue, 21 Jan 2003 10:35:25 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: model draft comments Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02583 Hello Jamal, By seeing you first email 2 weeks back, I responded to you privately and mentioned that I vacation time. I resumed office yesterday and catching up with the mailing list discussion hopefully able to participate actively by evening. Anyway, thanks for your concern. BTW, I agreed to Alex, Hormuzd comments and also with Joel,Alan, we should focus on how we are solving issues rather than who is responding to the issues. Regards Ramg > -----Original Message----- > From: ext Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Tuesday, January 21, 2003 4:09 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: model draft comments > > > Why is Hormuzd doing all the responding on behalf of the model draft's > authors? Occasionaly Joel appears, you pose a question to him then he > disappears. > I think we should kill the current model draft and start a > new one perhaps > with new authors. I honestly see no point in discussing it at > all if the > authors dont bother to participate. > > cheers, > jamal > > On Tuesday 21 January 2003 09:48, Alan DeKok wrote: > > "Khosravi, Hormuzd M" wrote: > > > One clarification before I reply, I was looking at model-01 draft > > > and section 5 does not have item 10. do you mean section 4.3.2 ? > > > > Sorry. I meant the requirements document, section 5, item 10. > > > > My comments were not that the requirments document had to > be revised, > > but that the model document should make it clear how it will satisfy > > those requirements. Simply saying "we represent a graph > topology and > > the CE interprets it" is insufficient for me to understand how it's > > supposed to work. > > > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 11:08:02 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03766 for ; Tue, 21 Jan 2003 11:08:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008A078D@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 11:11:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33405758 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 11:11:20 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 11:11:20 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4161067 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 11:11:19 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <3E2D5DD2.C5235DD4@idt.com> <3E2D5DD2.C5235DD4@idt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> Date: Tue, 21 Jan 2003 11:11:03 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03012104084401.00998@jzny> Precedence: list I will presume that you did not intend to be rude. The reason I have stopped responding to most of your questions is that although two of you are raising issues, I have not been able to understand the issues. I have tried several times. I and other author's have tried to explain the reasoning in the document. You are certainly free to write an internet draft that takes the perspective you think is helpful. Such a draft might allow others in the working group to understand what problem you are trying to raise. We might decide that yours was a better direction. However, I can not see throwing away the current draft without having a working group accepted alternative in hand. Yours, Joel M. Halpern At 04:08 AM 1/21/2003 -0500, Jamal Hadi Salim wrote: >Why is Hormuzd doing all the responding on behalf of the model draft's >authors? Occasionaly Joel appears, you pose a question to him then he >disappears. >I think we should kill the current model draft and start a new one perhaps >with new authors. I honestly see no point in discussing it at all if the >authors dont bother to participate. > >cheers, >jamal > >On Tuesday 21 January 2003 09:48, Alan DeKok wrote: > > "Khosravi, Hormuzd M" wrote: > > > One clarification before I reply, I was looking at model-01 draft > > > and section 5 does not have item 10. do you mean section 4.3.2 ? > > > > Sorry. I meant the requirements document, section 5, item 10. > > > > My comments were not that the requirments document had to be revised, > > but that the model document should make it clear how it will satisfy > > those requirements. Simply saying "we represent a graph topology and > > the CE interprets it" is insufficient for me to understand how it's > > supposed to work. > > > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 11:44:49 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04713 for ; Tue, 21 Jan 2003 11:44:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008A093D@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 11:48:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33410472 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 11:48:12 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 11:48:11 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 32D701F005B for ; Tue, 21 Jan 2003 11:48:11 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 164AA1F0059 for ; Tue, 21 Jan 2003 11:48:11 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <3E2D5DD2.C5235DD4@idt.com> <3E2D5DD2.C5235DD4@idt.com> <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E2D79CA.61133D42@idt.com> Date: Tue, 21 Jan 2003 11:48:10 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > > The reason I have stopped responding to most of your questions is that > although two of you are raising issues, I have not been able to understand > the issues. I mostly agree with the current model draft. I've said so previously on the list. What I disagree with are the extensions to that draft which have been discussed recently. e.g. The draft talks about FE topology, but does *not* say how you would build a network device which uses that topology to handle arbitrary network traffic. Yet discussions on the list show that some people think that step is easy. Call me dumb, but I don't understand how that would work. I think it's hard. And as justification for that opinion, I have not yet seen *any* explanation on the list as to how that would be done. There have just been assertions that it's not hard. That's not a way to achieve consensus. Saying that we can implement the diffserv model and have a CE understand that topology doesn't help. I already know that we can hand-code applications for any network protocol or polocy. I want to know how we can automate the process of a CE configuring network policy. I've been told it's easy, but I haven't been told why. > You are certainly free to write an internet draft that takes the > perspective you think is helpful. Such a draft might allow others in the > working group to understand what problem you are trying to raise. We might > decide that yours was a better direction. A short description of my opinion follows, as an analogy to the OSI seven layer model. It's not perfect, but it gives a glimpse of where my issues lie. ForCES as an OSI 7 layer model 1) Physical We have Physical FE's on a forwarding plane. 2) Data link The PFE's do error checking on their physical connections. 3) Network layer. The PFE's are configured in some kind of network on the forwarding plane. 4) Transport layer The CE has some connection to the PFE's, to manage & configure them 5) Session layer The CE manages how the FE deals with session information. (e.g. TCP accelerators, stateful firewalls, etc) 6) Presentation layer Management of data encapsulation (ipsec, etc) 7) Application layer The CE interacts with other devices on the network to act as a network-aware device. e.g. BGP, Diffserv, etc. My belief is that most everything up to layer 5 is well understood. Layer 6 is a little trickier, and layer 7 is extremely difficult. The discussions I've seen on the list appear to say that writing CE applications can be automated, once the graph topology and capabilities are known. My response is that if that were true, the most of the IETF working groups would disappear, and we could "compile" new network apps from a set of requirements. I think that the model document needs updating to address these issues, because it's silent on them. I don't have many objections to what the model document does say, however. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 12:04:28 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05283 for ; Tue, 21 Jan 2003 12:04:26 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.008A0884@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 12:07:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33411801 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:07:38 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 12:07:38 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4161240 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:07:37 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <3E2D5DD2.C5235DD4@idt.com> <3E2D5DD2.C5235DD4@idt.com> <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030121115240.02822da0@mail.stevecrocker.com> Date: Tue, 21 Jan 2003 12:07:19 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3E2D79CA.61133D42@idt.com> Precedence: list This is a fair question. Lets start with an easy cases, just to make sure that we are un the same page. Given a CE that understands diffserv, it will understand that for an AF service it will need a classifier (to select which traffic gets the service) a meter, and a set of markers on the ingress path. It will also understand that for the egress path it will need a mark sensitive queue selector (to get the traffic into the queue it is using for AF1x) and a mark sensitive RED element if it has one and wants to use it. It may well have logic that changes the input behavior if the available outputs do not have mark sensitive RED. In one sense this is easy. In another sense, this is extremely difficult. Trying to go from a service description of the form [given 10.x traffic AF1x, with these rate limits for red, yellow, green] to the sequence above is non-trivial. However, I do not expect the CE to make that transform. The CE will be given a set of descriptions along the line of the QDDIM model or diffserv model, which defines the actual processing required. It can then look at the capabilities of the FE and deploy the service. One could easily imagine a CE taht was smart enough to understand which FEs could and could-not deliver this service given their configuration and resource limits. Now, a harder case is trying to build a service that involves classifying, decapsulating, reclassifying, metering, etc. Clearly, again, this will first require that some external logic takes a description of the form [deliver service X to users A-C via IPSec from Q] and transform that into the necessary processing elements. I do not expect the CE to perform taht transform. Given the transformed service description, the CE will then evaluate what FEs can be adjusted to deliver the service. This will likely require using / creating a path that was not used before. Whether that is done by reconfiguring the paths, or by using an available path, will depend upon the FE implementation. Probably the hardest part of the CEs algorithmic job will be determining when it can use the same parts for different services. The place where this will be most complicated is in the handling of output queues and their scheduling. The interaction of scheduling disciplines and the resulting service delivery may be intractable. But the interaction of classifiers, policers / meters, markers, encaps / decaps elements, etc is easily modeled and understood by software. I believe that the CE can find available resources to meet its needs. Understanding both the capacity and connectivity flexibility of the blocks inside the FE is very helpful for the CE in doing this job. I hope that this helps explain the assumptions I at least am making. Yours, Joel M. Halpern At 11:48 AM 1/21/2003 -0500, Alan DeKok wrote: >I don't understand how that would work. I think >it's hard. And as justification for that opinion, I have not yet seen >*any* explanation on the list as to how that would be done. There have >just been assertions that it's not hard. That's not a way to achieve >consensus. > > > Saying that we can implement the diffserv model and have a CE >understand that topology doesn't help. I already know that we can >hand-code applications for any network protocol or polocy. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 12:05:32 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05322 for ; Tue, 21 Jan 2003 12:05:30 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.008A09E2@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 12:08:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33411854 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:08:54 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 12:08:54 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h0LGj7Dp012730 for ; Tue, 21 Jan 2003 08:45:08 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.2] References: <3E2D5DD2.C5235DD4@idt.com> <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Approved-By: Jamal Hadi Salim Message-ID: <03012106162705.00998@jzny> Date: Tue, 21 Jan 2003 06:16:27 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 8bit On Tuesday 21 January 2003 11:11, Joel M. Halpern wrote: > I will presume that you did not intend to be rude. Absolutely not the intent. I was more raising my hands in frustration. [Ram, i know you were away, but from your email you were supposed to be back last week monday - i was going to wait but this discussion got out of control.] In any case i am glad killing-the-draft idea woke people up. > The reason I have stopped responding to most of your questions is that > although two of you are raising issues, I have not been able to understand > the issues. I have tried several times. > I and other author's have tried to explain the reasoning in the document. > The main contention as i see it are: a) Forces is not just about QoS and diffserv alone; in my opinion they are merely examples of the larger forces model. Diffserv and QoS fit within the larger ForCES model but the vice-versa is not necessarily true. b) There are infact layers for the model to make sense: The lower two being a policy/service layout of a graph of functional block/elements and beneath it being the functional block itself which is not aware of the larger picture. The draft model does lump the two layers in b) together or at least does not unambigously declare them separate. To me the above makes any discussion on the draft hard to start. > You are certainly free to write an internet draft that takes the > perspective you think is helpful. Such a draft might allow others in the > working group to understand what problem you are trying to raise. We might > decide that yours was a better direction. > > However, I can not see throwing away the current draft without having a > working group accepted alternative in hand. > I didnt wanna exercise the option of releasing another draft yet(i did in the case of the requirements draft after similar frustration); i was hoping we could reach some understanding. cheers, jamal > Yours, > Joel M. Halpern > > At 04:08 AM 1/21/2003 -0500, Jamal Hadi Salim wrote: > >Why is Hormuzd doing all the responding on behalf of the model draft's > >authors? Occasionaly Joel appears, you pose a question to him then he > >disappears. > >I think we should kill the current model draft and start a new one perhaps > >with new authors. I honestly see no point in discussing it at all if the > >authors dont bother to participate. > > > >cheers, > >jamal > > > >On Tuesday 21 January 2003 09:48, Alan DeKok wrote: > > > "Khosravi, Hormuzd M" wrote: > > > > One clarification before I reply, I was looking at model-01 draft > > > > and section 5 does not have item 10. do you mean section 4.3.2 ? > > > > > > Sorry. I meant the requirements document, section 5, item 10. > > > > > > My comments were not that the requirments document had to be revised, > > > but that the model document should make it clear how it will satisfy > > > those requirements. Simply saying "we represent a graph topology and > > > the CE interprets it" is insufficient for me to understand how it's > > > supposed to work. > > > > > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 12:43:52 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06515 for ; Tue, 21 Jan 2003 12:43:51 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.008A0B2B@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 12:47:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33414339 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:47:15 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 12:47:15 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 84B361F0059 for ; Tue, 21 Jan 2003 12:47:14 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 1F83D1F0058 for ; Tue, 21 Jan 2003 12:47:14 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <3E2D5DD2.C5235DD4@idt.com> <3E2D5DD2.C5235DD4@idt.com> <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> <5.1.0.14.0.20030121115240.02822da0@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E2D87A1.B7A72FF7@idt.com> Date: Tue, 21 Jan 2003 12:47:13 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > > This is a fair question. > > Lets start with an easy cases, just to make sure that we are un the same page. > Given a CE that understands diffserv, it will understand that for an AF > service it will need a classifier (to select which traffic gets the > service) a meter, and a set of markers on the ingress path. It will also > understand that for the egress path it will need a mark sensitive queue > selector (to get the traffic into the queue it is using for AF1x) and a > mark sensitive RED element if it has one and wants to use it. It may well > have logic that changes the input behavior if the available outputs do not > have mark sensitive RED. I agree. For me, the important concept in a CE "understanding" diffserv is that it probably does NOT need to explicitely know or manage the topology. The topology is implicit: it's diffserv. For well-known protocols and applications, a lot of the topology discussions disappear. > In one sense this is easy. > In another sense, this is extremely difficult. Trying to go from a service > description of the form [given 10.x traffic AF1x, with these rate limits > for red, yellow, green] to the sequence above is non-trivial. However, I > do not expect the CE to make that transform. The CE will be given a set of > descriptions along the line of the QDDIM model or diffserv model, which > defines the actual processing required. It can then look at the > capabilities of the FE and deploy the service. > One could easily imagine a CE taht was smart enough to understand which FEs > could and could-not deliver this service given their configuration and > resource limits. I agree. Some simple "sanity checking" of the topology by the CE is possible, even if it does nothing more than that. > Now, a harder case is trying to build a service that involves classifying, > decapsulating, reclassifying, metering, etc. Clearly, again, this will > first require that some external logic takes a description of the form > [deliver service X to users A-C via IPSec from Q] and transform that into > the necessary processing elements. I do not expect the CE to perform taht > transform. I would like to see that statement made explicit in the draft. e.g. An administrator can pick & choose network elements, and tell the CE "implement diffserv using A, B, and C". In this situation, the policy is human controlled, and all of the topology issues go away. > Probably the hardest part of the CEs algorithmic job will be determining > when it can use the same parts for different services. The FE can make that information available. If an administrator says "use element B for metering", then that element can know it's in use, and refuse to make itself available for implementing other functions. > But the interaction of classifiers, > policers / meters, markers, encaps / decaps elements, etc is easily modeled > and understood by software. I agree. A classifier may be able implement ACL's and routing simultaneously. In that case, it can make itself available twice, to the adminstrators policy engine. > I hope that this helps explain the assumptions I at least am making. It does. I think we're very close in outlook. We just have the communications barrier of a shared language to overcome. :) Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 12:50:19 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06687 for ; Tue, 21 Jan 2003 12:50:18 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008A0ACA@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 12:53:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33414550 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:53:24 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 12:53:23 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4161370 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:53:22 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <3E2D5DD2.C5235DD4@idt.com> <3E2D5DD2.C5235DD4@idt.com> <5.1.0.14.0.20030121110754.018615d8@mail.stevecrocker.com> <5.1.0.14.0.20030121115240.02822da0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030121125229.02843ce0@mail.stevecrocker.com> Date: Tue, 21 Jan 2003 12:52:55 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3E2D87A1.B7A72FF7@idt.com> Precedence: list I agree. We can and will add a statement along these lines to the draft. Yours, Joel M. Halpern At 12:47 PM 1/21/2003 -0500, you wrote: > I would like to see that statement made explicit in the draft. > > e.g. An administrator can pick & choose network elements, and tell the >CE "implement diffserv using A, B, and C". In this situation, the >policy is human controlled, and all of the topology issues go away. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 12:53:08 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06759 for ; Tue, 21 Jan 2003 12:53:07 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.008A0C14@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 12:56:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33414741 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 12:56:32 -0500 Received: from 143.182.124.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 12:56:31 -0500 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h0LHv9e00293 for ; Tue, 21 Jan 2003 17:57:09 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003012109543213771 for ; Tue, 21 Jan 2003 09:54:32 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 09:56:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Tue, 21 Jan 2003 09:56:28 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list FYI, Lily Yang, one of the co-authors, is on sabbatical until late February and is totally beyond the reach of email. The other authors have already responded. Note that the model draft is an individual contrib - it has not been accepted as a working group document. Alternative proposals are welcomed, or debate and changes to the current proposal. Cheers, David > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Tuesday, January 21, 2003 1:09 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] model draft comments > > > Why is Hormuzd doing all the responding on behalf of the model draft's > authors? Occasionaly Joel appears, you pose a question to him then he > disappears. > I think we should kill the current model draft and start a > new one perhaps > with new authors. I honestly see no point in discussing it at > all if the > authors dont bother to participate. > > cheers, > jamal > > On Tuesday 21 January 2003 09:48, Alan DeKok wrote: > > "Khosravi, Hormuzd M" wrote: > > > One clarification before I reply, I was looking at model-01 draft > > > and section 5 does not have item 10. do you mean section 4.3.2 ? > > > > Sorry. I meant the requirements document, section 5, item 10. > > > > My comments were not that the requirments document had to > be revised, > > but that the model document should make it clear how it will satisfy > > those requirements. Simply saying "we represent a graph > topology and > > the CE interprets it" is insufficient for me to understand how it's > > supposed to work. > > > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 13:15:57 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07511 for ; Tue, 21 Jan 2003 13:15:55 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008A0B82@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 13:19:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33417050 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 13:19:03 -0500 Received: from 152.163.225.99 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 13:19:03 -0500 Received: from Aaudu2000@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id a.1db.6b4120 (16100) for ; Tue, 21 Jan 2003 13:19:00 -0500 (EST) Received: from aol.com (mow-d20.webmail.aol.com [205.188.139.136]) by air-id11.mx.aol.com (v90.10) with ESMTP id MAILINID114-0121131859; Tue, 21 Jan 2003 13:18:59 -0500 MIME-Version: 1.0 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: Aaudu2000@AOL.COM Message-ID: <79982FF9.05B00026.0218F5DE@aol.com> Date: Tue, 21 Jan 2003 13:18:59 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Jamal, Your policy/service idea is best kept at a much higher level than the framework that ForCES is being specified for. This is the application that uses ForCES to provide services. Again, I'll suggest a quick look at the work that has been done under IEEE P1520 (specification for programmable router interfaces). (You can point your browser to your favorite search engine and search for IEEE P1520 to get to it,..or you can go to the IEEE's web site). In there, you'll see three main layers: Service abstraction, Resource Abstraction and then Hardware Abstraction in that order. You can have a policy layer on top of the service layer. The resource abstraction is basically your building blocks (shaper, dropper, filter,..etc). The service layer programs the lower resource layer to provide specific services,..which in turn programs the hardware layer. In ForCES, the service layer is the high level application that sits in CE that makes sense of the topology information obtained from FEs. It then configures the topology for specific services. Now, the level of that configuration may be different. It may just be parameter modifications, or in the extreme case, it may also include placing resources in a particular data path. The FE will be the programmable hardware. Cheers, Alex. In a message dated 1/21/2003 6:16:27 AM Eastern Standard Time, Jamal Hadi Salim writes: > >The main contention as i see it are: >a) Forces is not just about QoS and diffserv alone; in my opinion they are >merely examples of the larger forces model. Diffserv and QoS fit within the >larger ForCES model but the vice-versa is not necessarily true. >b) There are infact layers for the model to make sense: The lower two being a >policy/service layout of a graph of functional block/elements and beneath it >being the functional block itself which is not aware of the larger picture. > >The draft model does lump the two layers in b) together or at least does not >unambigously declare them separate. > >To me the above makes any discussion on the draft hard to start. > >> You are certainly free to write an internet draft that takes the >> perspective you think is helpful. Such a draft might allow others in the >> working group to understand what problem you are trying to raise. We might >> decide that yours was a better direction. >> >> However, I can not see throwing away the current draft without having a >> working group accepted alternative in hand. >> > >I didnt wanna exercise the option of releasing another draft yet(i did in the >case of the requirements draft after similar frustration); i was hoping we >could reach some understanding. > >cheers, >jamal > >> Yours, >> Joel M. Halpern >> >> At 04:08 AM 1/21/2003 -0500, Jamal Hadi Salim wrote: >> >Why is Hormuzd doing all the responding on behalf of the model draft's >> >authors? Occasionaly Joel appears, you pose a question to him then he >> >disappears. >> >I think we should kill the current model draft and start a new one perhaps >> >with new authors. I honestly see no point in discussing it at all if the >> >authors dont bother to participate. >> > >> >cheers, >> >jamal >> > >> >On Tuesday 21 January 2003 09:48, Alan DeKok wrote: >> > > "Khosravi, Hormuzd M" wrote: >> > > > One clarification before I reply, I was looking at model-01 draft >> > > > and section 5 does not have item 10. do you mean section 4.3.2 ? >> > > >> > > Sorry. I meant the requirements document, section 5, item 10. >> > > >> > > My comments were not that the requirments document had to be revised, >> > > but that the model document should make it clear how it will satisfy >> > > those requirements. Simply saying "we represent a graph topology and >> > > the CE interprets it" is insufficient for me to understand how it's >> > > supposed to work. >> > > >> > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 22:36:45 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20415 for ; Tue, 21 Jan 2003 22:36:45 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008A24C5@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 22:40:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33458563 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 22:40:09 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 22:40:09 -0500 Received: from localhost (hadi@localhost) by znyx.com (8.9.3/8.9.3) with ESMTP id TAA07009 for ; Tue, 21 Jan 2003 19:40:13 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Message-ID: Date: Tue, 21 Jan 2003 19:40:13 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list On Tuesday 21 January 2003 12:07, Joel M. Halpern wrote: [..] > One could easily imagine a CE taht was smart enough to understand which FEs > could and could-not deliver this service given their configuration and > resource limits. Or FEs that are capable of rejecting configs ... > > Now, a harder case is trying to build a service that involves > classifying, > decapsulating, reclassifying, metering, etc. Clearly, again, this will > first require that some external logic takes a description of the form > [deliver service X to users A-C via IPSec from Q] and transform that > into > the necessary processing elements. I do not expect the CE to perform > taht transform. I am glad ipsec shows up - it's good to see a digression away from the dogma of QoS and diffserv and related elements. Essentially the way i see it is: [deliver service X to users A-C via IPSec from Q] is a description of a service in a natural language; probaly the highest layer in the chain but has no place in a forces model. Below it is a composition of elements which someone/software creates to deliver this service. This composition of elements is a policy. At the lowest layer is the per-element description to deliver the policy. I think the service model is a different problem domain; however, i certainly see the other two as items that have a role in the model. I deleted most of what you wrote because i agree with it; My problem is those two issues which i'll repeat one more time: 1) the fact that qos/diffserv is a subset of the forces model. In other words i should be able to use forces (model and protocol) to not only be able to express diffserv, but also things like TCP splicing etc. This is not clear to me, maybe because qos is spoken with reverence around here. 2) the need for the layering i described to be clear. I would like to move to critiquing the draft itself but i find it hard without clarity on these two issues. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 21 22:46:09 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20547 for ; Tue, 21 Jan 2003 22:46:08 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008A2646@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 22:49:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33458924 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jan 2003 22:49:32 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 22:49:32 -0500 Received: from localhost (hadi@localhost) by znyx.com (8.9.3/8.9.3) with ESMTP id TAA07032 for ; Tue, 21 Jan 2003 19:49:37 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Message-ID: Date: Tue, 21 Jan 2003 19:49:37 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Alex, I forgot about those layers in 1520. Essentially it is along the lines of what i was getting to. I am not sure i understand why you say this layering cant be part of the model. In my opinion when you provide a policy, you are describing a service instantiation and if you are going to provide a protocol tga cheers, jamal On Tuesday 21 January 2003 13:18, Alex Audu wrote: > Jamal, > > Your policy/service idea is best kept at a much higher level > than the framework that ForCES is being specified for. This is the > application that uses ForCES to provide services. > > Again, I'll suggest a quick look at the work that has been > done under IEEE P1520 (specification for programmable router > interfaces). (You can point your browser to your favorite > search engine and search for IEEE P1520 to get to it,..or > you can go to the IEEE's web site). > > In there, you'll see three main layers: Service abstraction, > Resource Abstraction and then Hardware Abstraction in that > order. You can have a policy layer on top of the service layer. The > resource abstraction is basically your building blocks (shaper, dropper, > filter,..etc). The service layer programs the lower resource layer to > provide specific services,..which in turn programs the hardware layer. > > In ForCES, the service layer is the high level application > that sits in CE that makes sense of the topology information > obtained from FEs. It then configures the topology for > specific services. Now, the level of that configuration may > be different. It may just be parameter modifications, or in > the extreme case, it may also include placing resources in a > particular data path. The FE will be the programmable hardware. > > > Cheers, > Alex. From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Wed Jan 22 13:33:05 2003 Received: from grape.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03157 for ; Wed, 22 Jan 2003 13:33:04 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <2.0033BA0D@grape.ease.lsoft.com>; Wed, 22 Jan 2003 13:36:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33515541 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Jan 2003 13:36:30 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Jan 2003 13:36:26 -0500 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4164142 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Jan 2003 13:36:25 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030122132945.018dfe18@mail.stevecrocker.com> Date: Wed, 22 Jan 2003 13:36:07 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list I hope I can clarify these two questions. On the question of supporting things other than QoS, the only possible answer is "somewhat". We will be producing a list of functional blocks for the model. We will try to include more than just the diffserv blocks. However, There will be things people want to do that we will not include. We have to bound the work somewhat. On the question of layering, I suspect that the problem lies in how people look at the word policy. Note that the QPIM and QDDIM models are both "policy". However, I am much more comfortable with expecting the CE to handle a description at the QDDIM level of specificity rather than expecting it to handle a QPIM level description. It would not surprise me if we need to tighten up the text in the model draft in this regard. We currently do not discuss where a CE fits in the overall conceptual model of policy management. We avoid this for many reasons, probably the largest being that the real practice deviates wildly from theory. The next largest is that this is not the forces applicability statement. That document will describe where the forces component live in the real network and how they interact with the rest of the systems. I hope that this helps you understand the assumptions that the authors have made to date in working on the draft. Yours, Joel M. Halpern At 07:40 PM 1/21/2003 -0800, you wrote: >Essentially the way i see it is: [deliver service X to users A-C via IPSec >from Q] is a description of a service in a natural language; probaly the >highest layer in the chain but has no place in a forces model. Below it is >a composition of elements which someone/software creates to deliver this >service. This composition of elements is a policy. At the lowest layer is >the per-element description to deliver the policy. >I think the service model is a different problem domain; however, i >certainly see the other two as items that have a role in the model. > >I deleted most of what you wrote because i agree with it; >My problem is those two issues which i'll repeat one more time: >1) the fact that qos/diffserv is a subset of the forces model. In other >words i should be able to use forces (model and protocol) to not only be >able to express diffserv, but also things like TCP splicing etc. This is >not clear to me, maybe because qos is spoken with reverence around here. > >2) the need for the layering i described to be clear. > >I would like to move to critiquing the draft itself but i find it hard >without clarity on these two issues. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 23 09:49:49 2003 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09246 for ; Thu, 23 Jan 2003 09:49:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008A5FB2@cherry.ease.lsoft.com>; Thu, 23 Jan 2003 9:53:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33592672 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 Jan 2003 09:53:14 -0500 Received: from 208.2.156.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 23 Jan 2003 09:53:14 -0500 Received: from jzny (electra.znyx.com [208.2.156.2]) by enforcer.znyx.com (8.12.3/8.12.3) with SMTP id h0NETBDp031521 for ; Thu, 23 Jan 2003 06:29:11 -0800 (PST) Content-Type: Multipart/Mixed; charset="iso-8859-1"; boundary="------------Boundary-00=_Y7N5FQFMKHLOH3TTY8CD" X-Mailer: KMail [version 1.2] References: <5.1.0.14.0.20030122132945.018dfe18@mail.stevecrocker.com> MIME-Version: 1.0 Approved-By: Jamal Hadi Salim Message-ID: <03012301551000.01150@jzny> Date: Thu, 23 Jan 2003 01:55:10 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: model draft comments To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030122132945.018dfe18@mail.stevecrocker.com> Precedence: list --------------Boundary-00=_Y7N5FQFMKHLOH3TTY8CD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit On Wednesday 22 January 2003 13:36, Joel M. Halpern wrote: > I hope I can clarify these two questions. > > On the question of supporting things other than QoS, the only possible > answer is "somewhat". We will be producing a list of functional blocks for > the model. We will try to include more than just the diffserv > blocks. However, There will be things people want to do that we will not > include. We have to bound the work somewhat. > "Somewhat" worries me. I believe that line of reasoning is based on the fact theres some attachment to the QoS model. Ive attached a small file mostly because the graphics will get mangled if i send it in the email txt. I claim i can easily model a diffserv router, and anything else which may have a FE-CE sort of relationship ranging from bridging, ipv6 forwarding, ipip tunneling to tcp-splicing etc. The sample model doesnt care what those actions are, as long as something in the CE (via the forces protocol) is able to control them and tell them what to do. [There is even publicly available code that runs to prove it]. Sure the charter restricts us to go as far as diffserv but it does not say that QoS is dogma. We should be able to _at least_ express diffserv. I am fine with building all the minimal blocks needed (forwarding and diffserv) but not restricting the Forces protocol to have just that capability. If that is not the goal of Forces then i have been, regretfully, wasting my time. Note: i am not saying we cant take advantage of the QoS modeling experiences; where i have a problem is that Forces modeling (or protocol) becomes QoS first then squeeze other semantics later - "somewhat". > On the question of layering, I suspect that the problem lies in how people > look at the word policy. Note that the QPIM and QDDIM models are both > "policy". However, I am much more comfortable with expecting the CE to > handle a description at the QDDIM level of specificity rather than > expecting it to handle a QPIM level description. It would not surprise me > if we need to tighten up the text in the model draft in this regard. > Google just told me of QPIM and QDDIM and she wants me to filter the noise - i promise to read more later; i scanned some slide presentation on QPIM and i saw the QoS annotations there as well (infact the Q there stands for Qos). Agreed, it depends on the semantics of "policy" used. My use of the word "policy" isnt quiet in the spirit of QoS policy management rather more in relation to the classical OS description of policies and mechanisms. Policies in the CE tell the individual mechanisms on the FE what to do. [It eventually boils down to the same classical meanings but spiced out differently.] > We currently do not discuss where a CE fits in the overall conceptual model > of policy management. We avoid this for many reasons, probably the largest > being that the real practice deviates wildly from theory. The next largest > is that this is not the forces applicability statement. That document will > describe where the forces component live in the real network and how they > interact with the rest of the systems. > I dont think we need to describe where things live in relation to policy management. I agree thats another ball game. However, once a policy has been digested into something the CE understands and can use to configure an FE then that is, IMO, a core component of the model discusion. From a modeling perspective, thats well represented by graphs. > I hope that this helps you understand the assumptions that the authors have > made to date in working on the draft. > I have just not been comfortable with the assumptions. cheers, jamal > Yours, > Joel M. Halpern > > At 07:40 PM 1/21/2003 -0800, you wrote: > >Essentially the way i see it is: [deliver service X to users A-C via IPSec > >from Q] is a description of a service in a natural language; probaly the > >highest layer in the chain but has no place in a forces model. Below it is > >a composition of elements which someone/software creates to deliver this > >service. This composition of elements is a policy. At the lowest layer is > >the per-element description to deliver the policy. > >I think the service model is a different problem domain; however, i > >certainly see the other two as items that have a role in the model. > > > >I deleted most of what you wrote because i agree with it; > >My problem is those two issues which i'll repeat one more time: > >1) the fact that qos/diffserv is a subset of the forces model. In other > >words i should be able to use forces (model and protocol) to not only be > >able to express diffserv, but also things like TCP splicing etc. This is > >not clear to me, maybe because qos is spoken with reverence around here. > > > >2) the need for the layering i described to be clear. > > > >I would like to move to critiquing the draft itself but i find it hard > >without clarity on these two issues. > > > >cheers, > >jamal --------------Boundary-00=_Y7N5FQFMKHLOH3TTY8CD Content-Type: text/plain; charset="iso-8859-1"; name="model2" Content-Disposition: attachment; filename="model2" Content-Transfer-Encoding: base64 TGV0cyBzdGFydCB3aXRoIHRoaXMgYmxhdGFudCByaXAgb2ZmIGZyb20gdGhlIGRpZmZzZXJ2IG1v ZGVsIHdpdGggYSBzbWFsbApjaGFuZ2U6CgogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICB8IGluZ3Jlc3Mg aS9mIHwgICArLS0tLS0tLS0tKyAgIHwgZWdyZXNzIGkvZiAgfAogICAgICAtLS0tLS0tLT58ICBj bGFzc2lmeSwgIHwtLT58IHJvdXRpbmcgfC0tPnwgIGNsYXNzaWZ5LCAgfC0tLS0+CiAgICAgIGRh dGEgICAgIHwgemVybyBvciBtb3JlfCAgIHwgIGNvcmUgICB8ICAgfHplcm8gb3IgbW9yZSB8ZGF0 YSBvdXQKICAgICAgaW4gICAgICAgfCAgYWN0aW9ucywgICB8ICAgKy0tLS0tLS0tLSsgICB8ICBh Y3Rpb25zLCAgIHwKICAgICAgICAgICAgICAgfCAgcXVldWluZyAgICB8ICAgICAgICAgICAgICAg ICB8ICBxdWV1aW5nICAgIHwKICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLSsKIApOb3RlIGkgZ290IHJpZCBvZiBtZXRlcmluZyBhbmQg cmVwbGFjZWQgaXQgd2l0aCAiemVybyBvciBtb3JlIiBhY3Rpb25zLgoKSW4gb3RoZXIgd29yZHMg bWV0ZXJpbmcsIGFsZ29yaXRobWljIGRyb3BwZXIgZXRjIGFyZSBqdXN0IGFjdGlvbnMgdGhhdCBm b2xsb3cKYSBjbGFzc2lmaWVyLiAKCkxldHMgcGVlayBpbnRvIG9uZSBvZiB0aGVzZSBibG9ja3Ms c2F5IGluZ3Jlc3M6CgoKICAgICAgICAgICstLS0tLS0tLS0tPC0tLS0tLS0tLS0tKyAKICAgICAg ICAgIFkgICAgICAgICAgICAgICAgICAgICAgXgogICAgICAgICAgWSAgICAgICAgICArLS0tLS0r ICAgICBeIAogICAgICAgICAgWSAgICAgICAgICB8ICAgICB8LS0tLS0qLS0tLS0tLS0tPiB0byBx dWV1ZXMvc2NoZWR1bGVyL2VncmVzcwogICAgICAgICAgWSAgICAgICAgICB8ICAgICB8ICAgICBZ CiAgICAgICAgICBZICAgICAgICAgIHwgICAgIHwgICAgIFkKICAgICAgICAgIFkgICAgICAgKy0+ fCAgICAgfCAgICAgWQogICAgICAgICstWS0tLSsgICB8ICB8ICAgICB8ICAgfF90ZXJtaW5hdGVf fCAKICAgICAgICB8ICAgIEF8LS0tKyAgKy0tLS0tKyAgICAKICAgICAgICB8ICAgIC58ICAgICAg QWN0aW9uKiAgIAogICAgIC0tPnwgICAgLnwgICAgICAgICAgCiAgICAgICAgfCAgICBCfC0tLSsg IAogICAgICAgICstLS0tLSsgICB8ICAKICAgICAgQ2xhc3NpZmllciAgKy0+CgpBY3Rpb24qIGlz IGEgY29sbGVjdGlvbiAoemVybyBvciBtb3JlKSBvZiBzZXJpYWxpemVkIGFjdGlvbnMgd2hpY2gg YXJlIApzaW5nbGUgaW5wdXQgYnV0IGNhcGFibGUgb2YgbXVsdGktb3V0cHV0LiBUaGUgbXVsdGkt b3V0cHV0cyBhcmUgcmVzdWx0cyAKb2YgY29uZGl0aW9uYWxzIChleGFtcGxlIHVuZGVyIGNvbmRp dGlvbiB4IGdvdG8gZWxlbWVudEEgdW5kZXIgY29uZGl0aW9uIAp5IGdvdG8gZWxlbWVudEIgZWxz ZSBnb3RvIGVsZW1lbnRDKS4gQSBtZXRlciBpbiB0aGUgZGlmZnNlcnYgbW9kZWwgZml0cyBhcyAK YW4gZWxlbWVudCB3aGljaCBkb2VzIGNvbmRpdGlvbmFscy4KVGhlIHBhdGggZnJvbSBhbiBhY3Rp b24qIGNvdWxkIGxlYWQ6Ci0gIGVpdGhlciBiYWNrIHRvIGEgY2xhc3NpZmllciBvciAKLSBvbndh cmQgdG8gYSBxdWV1ZS9zY2hlZHVsaW5nIHBhdGggKG9yIGlmIHRoaXMgd2FzIGluZ3Jlc3MgdGhl biB0aGUgcGF0aCAKY291bGQgYWxzbyBsZWFkIHRvIHRoZSBlZ3Jlc3Mgc2lkZSkuIAotIFRoZSBy ZXN1bHQgb2YgYW4gYWN0aW9uIGV4ZWN1dGlvbiBjb3VsZCBhbHNvIGJlIHRlcm1pbmF0aW9uIG9m IHRoZSBmbG93IChlZyAKYSBkcm9wKS4KCkVhY2ggYWN0aW9uIG1heSBtYWludGFpbiBzdGF0ZSB0 byBtYW5hZ2UgaXRzIGluc3RhbmNlcyAoYW5kIHRoZWlyIApvcGVyYXRpb25zKS4gQSBwb2xpY3kg ZGVmaW5lcyB0aGUgZGF0YXBhdGggd2hpY2ggaW5jbHVkZXMgdGhlIApncmFwaCB0aGF0IGRlZmlu ZXMgaWluc3RhbmNlcyBvZiBhY3Rpb25zIGhhbmdpbmcgb2ZmIGEgY2xhc3NpZmllci4KCg== --------------Boundary-00=_Y7N5FQFMKHLOH3TTY8CD--