2002 Message-Id: Date: Wed, 29 May 2002 16:16:58 -0700 From: "Putzolu, David" Subject: ForCES Requirements Last Call issue resolution MIME-Version: 1.0 Content-Type: text/plain All, Based on the list feedback and the responses of the design team please find below the proposed issue resolution for the ForCES Requirements last call that just completed. The design team has been asked to issue a new rev of the requirements that incorporates the changes proposed below. Once that is available, a short (1 week) last call will be held to review the changes before this document is forwarded to the ADs. If any issues were missed or the resolutions are not properly documented please post a note to the list ASAP. Thanks, David --- cut here --- Issue: Need for both a capabilities model and a state model Resolution: Include in new rev of requirements. Lily Yang has proposed some text that may be useful. Issue: All failure notifications should be supported not just "increase/decrease in available resources." Resolution: Include in new rev. of requirements. Issue: Should the requirements specify a minimal set of functions? Resolution: New rev. will include forwarding function as the minimum. Issue: Are there CE model requirements that need to be included? Resolution: Each requirement on the FE probably has a corresponding control function on the CE - issue addressed. Issue: FE should also be required to support error reporting and monitoring. Resolution: Include in new rev of requirements. 2002 Message-Id: Date: Fri, 24 May 2002 13:40:35 -0700 From: "Putzolu, David" Subject: Accept Framework individual contrib as WG doc? MIME-Version: 1.0 Content-Type: text/plain All, A new version of the ForCES Framework individual contribution was submitted last week and the authors have requested that it be accepted as a working group document. This document is intended to satisfy the charter deliverable of "An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them." Patrick and I would like the list to review and comment whether this draft is ready to be accepted as a ForCES working group document. Note that acceptance as a working group document associates this document with the ForCES WG. It does not grant formal standards status to the document and the document will remain open to change or removal. Please submit your comments and recommendation to the mailing list by Friday, May 31, 2002. URL: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.txt Thanks, David Lily Yang wrote: >Patrick, David and all -- > >On behalf of my co-authors Ram Dantu, >Todd Anderson and myself, I would like >to request the WG review this framework >draft and consider accepting it as a >WG document. > >Lily > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > Sent: Wednesday, May 15, 2002 11:13 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > Hi, all -- > We submitted version 01 of the framework draft last week after a major > rewrite: > * added more description and diagrams to illustrate different physical > configuration examples of ForCES CE/FE. > * added examples of FE topology. > * restructure the text to focus more on ForCES operation > phases (pre- and > post- association, reestablishment, etc.) > * added examples to illustrate the handshake between CE and > FE during these > operational phases. > > please let us know what you think -- are these > examples/diagrams useful? > Have we missed anything important? Any comments on the draft > are welcome! > > Thanks, > Lily 2002 Message-Id: Date: Thu, 23 May 2002 16:44:02 -0400 From: "Joel M. Halpern" Subject: Re: Requirements Document - Capabilities Model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The DiffServ model is definitely not a capabilities model. There is no way to express the fact that a given implementation is or is not capable of having more than one queue, more than 0 markers, more than 0 meters, etc, much less the number and kinds of meters, markers, queues, etc that it can have. There are places where the Requirements document implies that the model is both a capability and a state model. However, section 6 FE Model explicitly states that the model is a capabilities model. Yours, Joel M. Halpern PS: In other modeling work in and around the IETF it is referred to as a state model(or sometimes a configuration model), not an instance model. I don't much care exactly what words we use to seaparte the two kinds of models, but they are different, and need to be distinguished. At 01:33 PM 5/23/2002 -0700, Khosravi, Hormuzd M wrote: >Hi Joel > >Thanks for the comments. If I understand you correctly, you >are saying that we need a Capabilities Model which expresses >all the possible caps and then an Instance Model which >specifies the instances of those caps on the FE. I think >the DiffServ model has both these, the MIB/PIB defines all >the possible caps and has place holder for instance Ids which >are used in the protocol at run-time. Do correct me if I am >wrong. > >Anyways I think we already imply that we need both these in >the Requirements. Is there any particular text that you think >implies otherwise ?? > >regards >Hormuzd >-----Original Message----- >From: Joel M. Halpern [mailto:joel@stevecrocker.com] >Sent: Thursday, May 23, 2002 1:01 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Requirements Document - Capabilities Model > > >In reviewing the Requirements document and the proposed Architecture (or >framework) document, I realized that from my perspective there is an >additional piece of the puzzle that should be discussed along with the FE >model in the requirements document. > >The requirements document describes an FE model, and indicates that it is a >capabilities model. A capabilities model is a representation of what kinds >of operations something can perform, and frequently includes resource >availability (since resources have a direct effect on capability). >However, to control an FE, a CE needs to know more than just what it is >capable of. It needs to know what the current configuration (state) of the >device is. For example, if the CE is adding another filter, and wants to >cause traffic that matches that filter to be directed to an existing meter >or marker, then the CE must know how to refer to that meter or marker, and >the FE must understand that reference properly. Therefore, there is a >shared model of the actual current state of the FE, which the CE >manipulates and the FE uses to manipulate its actual behavior. >The DiffServ conceptual model (and MIB / PIB) which have been mentioned as >starting points for the capabilities model are actually state models, not >capabilities models. There is no way to tell from these models how many >filters a device can handle, or whether it is capable of >metering. However, you can tell at any given time exactly what filters it >has, how they connect to markers, meters, queues, etc. When you want to >configure additional processing elements into the processing path, you >reference the elements of this model. > >Thus, the requirements document should call out the need for both a >capabilities model and a state model. > >Yours, >Joel M. Halpern > >PS: I am sorry that I am bringing this issue up in last call. Fortunately, >not much text is required to resolve this. 2002 Message-Id: Date: Thu, 23 May 2002 16:00:59 -0400 From: "Joel M. Halpern" Subject: Requirements Document - Capabilities Model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In reviewing the Requirements document and the proposed Architecture (or framework) document, I realized that from my perspective there is an additional piece of the puzzle that should be discussed along with the FE model in the requirements document. The requirements document describes an FE model, and indicates that it is a capabilities model. A capabilities model is a representation of what kinds of operations something can perform, and frequently includes resource availability (since resources have a direct effect on capability). However, to control an FE, a CE needs to know more than just what it is capable of. It needs to know what the current configuration (state) of the device is. For example, if the CE is adding another filter, and wants to cause traffic that matches that filter to be directed to an existing meter or marker, then the CE must know how to refer to that meter or marker, and the FE must understand that reference properly. Therefore, there is a shared model of the actual current state of the FE, which the CE manipulates and the FE uses to manipulate its actual behavior. The DiffServ conceptual model (and MIB / PIB) which have been mentioned as starting points for the capabilities model are actually state models, not capabilities models. There is no way to tell from these models how many filters a device can handle, or whether it is capable of metering. However, you can tell at any given time exactly what filters it has, how they connect to markers, meters, queues, etc. When you want to configure additional processing elements into the processing path, you reference the elements of this model. Thus, the requirements document should call out the need for both a capabilities model and a state model. Yours, Joel M. Halpern PS: I am sorry that I am bringing this issue up in last call. Fortunately, not much text is required to resolve this. 2002 Message-Id: Date: Thu, 23 May 2002 15:12:22 -0700 From: "Yang, Lily L" Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Since the motivation of an FE model is to allow CEs later to control and configure FEs' behavior via ForCES protocol, it becomes essential to examine and understand what kind of control and configuration CEs might do to FEs. Maybe we can categorize them into 3 kinds. The first kind of control and configuration is the simplest of all. It assumes that each FE's capability is already given and remains static in its lifetime, and CEs can only control its behavior by manipulating its state. For example, an FE may provide a certain QoS function consisting of one classifier with 3 filters, connected to fixed number of meters, markers, queues etc. But the way these blocks connected is fixed and given. If such a configuration remains static during FE's lifetime, then all CE can control is the parameters associated with each block. But CE can not reconfigure the topology (among classifiers, meters, markers, queues, etc.) dynamically, such as adding another meter or queue onto the FE on the fly. For this kind of control and configuration purpose, the useful FE model is consisted of the state information that FEs allow CEs to manipulate and the statistics and events that FEs can collect and report back to CEs. Such a state model doesn't need to describe a lot of other information, like the packet formats supported between a particular meter and a particular counter, for example. Because that is fixed and given. The second kind of control and configuration builds on top of the first category by allowing "dynamic FE" control and configuration. Therefore, an FE state model is not sufficient now. A more powerful and flexible capability model is required to convey information such as "This FE can support one classifier with N filters, M meters, X queues, etc." It also becomes necessary to model the capability of the building blocks like classifiers, filters, meters etc. so that CE can configure them correctly. For example, it becomes necessary to describe the packet formats supported at each input and output of each block, because CEs need to have that information to allow correct reconfiguration of the graph. Therefore, both the FE state model and capability model become necessary for such dynamic control and configuration. The third kind of control and configuration is even more powerful and future looking. In addition to dynamic configuration, CEs might be even allowed to download a given functionality onto FEs. I am not sure how we model that yet. But we probably can get by without too concerned with this. My personal take on this is that we definetely MUST support the first kind of "static FE" control and configuraiton, and we MAY also allow the second kind of "dynamic FE". Therefore, a state model is a must and some flavor of a capability model would also be good. I guess when the requirement draft was written, this distinction was probably not made explicitly. I believe the requirements regarding the model in the document are still valid, except a few wording might need to be made more explicit, esp. when we say "FE capabilities". Lily > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Thursday, May 23, 2002 1:44 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Requirements Document - Capabilities Model > > > The DiffServ model is definitely not a capabilities model. > There is no way > to express the fact that a given implementation is or is not > capable of > having more than one queue, more than 0 markers, more than 0 > meters, etc, > much less the number and kinds of meters, markers, queues, > etc that it can > have. > > There are places where the Requirements document implies that > the model is > both a capability and a state model. However, section 6 FE Model > explicitly states that the model is a capabilities model. > > Yours, > Joel M. Halpern > > PS: In other modeling work in and around the IETF it is > referred to as a > state model(or sometimes a configuration model), not an > instance model. I > don't much care exactly what words we use to seaparte the two kinds of > models, but they are different, and need to be distinguished. > > At 01:33 PM 5/23/2002 -0700, Khosravi, Hormuzd M wrote: > >Hi Joel > > > >Thanks for the comments. If I understand you correctly, you > >are saying that we need a Capabilities Model which expresses > >all the possible caps and then an Instance Model which > >specifies the instances of those caps on the FE. I think > >the DiffServ model has both these, the MIB/PIB defines all > >the possible caps and has place holder for instance Ids which > >are used in the protocol at run-time. Do correct me if I am > >wrong. > > > >Anyways I think we already imply that we need both these in > >the Requirements. Is there any particular text that you think > >implies otherwise ?? > > > >regards > >Hormuzd > >-----Original Message----- > >From: Joel M. Halpern [mailto:joel@stevecrocker.com] > >Sent: Thursday, May 23, 2002 1:01 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: [FORCES] Requirements Document - Capabilities Model > > > > > >In reviewing the Requirements document and the proposed > Architecture (or > >framework) document, I realized that from my perspective there is an > >additional piece of the puzzle that should be discussed > along with the FE > >model in the requirements document. > > > >The requirements document describes an FE model, and > indicates that it is a > >capabilities model. A capabilities model is a > representation of what kinds > >of operations something can perform, and frequently includes resource > >availability (since resources have a direct effect on capability). > >However, to control an FE, a CE needs to know more than just > what it is > >capable of. It needs to know what the current configuration > (state) of the > >device is. For example, if the CE is adding another filter, > and wants to > >cause traffic that matches that filter to be directed to an > existing meter > >or marker, then the CE must know how to refer to that meter > or marker, and > >the FE must understand that reference properly. Therefore, > there is a > >shared model of the actual current state of the FE, which the CE > >manipulates and the FE uses to manipulate its actual behavior. > >The DiffServ conceptual model (and MIB / PIB) which have > been mentioned as > >starting points for the capabilities model are actually > state models, not > >capabilities models. There is no way to tell from these > models how many > >filters a device can handle, or whether it is capable of > >metering. However, you can tell at any given time exactly > what filters it > >has, how they connect to markers, meters, queues, etc. When > you want to > >configure additional processing elements into the processing > path, you > >reference the elements of this model. > > > >Thus, the requirements document should call out the need for both a > >capabilities model and a state model. > > > >Yours, > >Joel M. Halpern > > > >PS: I am sorry that I am bringing this issue up in last > call. Fortunately, > >not much text is required to resolve this. > 2002 Message-Id: Date: Thu, 23 May 2002 13:33:36 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Requirements Document - Capabilities Model MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Joel Thanks for the comments. If I understand you correctly, you are saying that we need a Capabilities Model which expresses all the possible caps and then an Instance Model which specifies the instances of those caps on the FE. I think the DiffServ model has both these, the MIB/PIB defines all the possible caps and has place holder for instance Ids which are used in the protocol at run-time. Do correct me if I am wrong. Anyways I think we already imply that we need both these in the Requirements. Is there any particular text that you think implies otherwise ?? regards Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Thursday, May 23, 2002 1:01 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Requirements Document - Capabilities Model In reviewing the Requirements document and the proposed Architecture (or framework) document, I realized that from my perspective there is an additional piece of the puzzle that should be discussed along with the FE model in the requirements document. The requirements document describes an FE model, and indicates that it is a capabilities model. A capabilities model is a representation of what kinds of operations something can perform, and frequently includes resource availability (since resources have a direct effect on capability). However, to control an FE, a CE needs to know more than just what it is capable of. It needs to know what the current configuration (state) of the device is. For example, if the CE is adding another filter, and wants to cause traffic that matches that filter to be directed to an existing meter or marker, then the CE must know how to refer to that meter or marker, and the FE must understand that reference properly. Therefore, there is a shared model of the actual current state of the FE, which the CE manipulates and the FE uses to manipulate its actual behavior. The DiffServ conceptual model (and MIB / PIB) which have been mentioned as starting points for the capabilities model are actually state models, not capabilities models. There is no way to tell from these models how many filters a device can handle, or whether it is capable of metering. However, you can tell at any given time exactly what filters it has, how they connect to markers, meters, queues, etc. When you want to configure additional processing elements into the processing path, you reference the elements of this model. Thus, the requirements document should call out the need for both a capabilities model and a state model. Yours, Joel M. Halpern PS: I am sorry that I am bringing this issue up in last call. Fortunately, not much text is required to resolve this. 2002 Message-Id: Date: Thu, 23 May 2002 11:21:13 -0500 From: Ram Dantu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May10-24 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex, Please see my comments. Regards Ram Dantu -----Original Message----- From: Alex Audu [mailto:Alex.Audu@alcatel.com] Sent: Thursday, May 23, 2002 10:44 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May10-24 Hello Ram, Sorry for the delay in responding to your last request. You are right; = the ForCES protocol requirement section also implies the responsibilities of CE. However, is it a = requirement that CE should handle control and signalling functions? Then we should so state in the document, = though it is implied in the draft. [RD] Start Please see definition of control element in Section 2. It reads "CEs handle functionality such as the execution of control=20 and signaling protocols." I hope this clarifies your question [RD] End Also, can we add language that FoCES protocol should support State = Monitoring/Management and Error Reporting? [RD] There is some text in items 13 and 14 of Section 7 (querying stats, = and asynchronous=20 notifications). We shall add text for error reporting and monitoring. Regards, Alex. Ram Dantu wrote: > Alex, > > In Section 6.5, there is a list of logical functions in FE > (This section defines a minimal set of logical functions > that any FE model MUST support. This minimal set DOES NOT imply > that all FEs must provide this functionality). > We can provide an example on how to achieve a forwarding function with = these functions. > I think this can go in the framework document or FE model document. > > Also, I think every ForCES requirement mandates a corresponding > function to be present in the FE and CE. So, I assume > CE should support all ForCES requirements. May be > you can give some examples with reference to some section ? > > Thanks > Ram Dantu > -----Original Message----- > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > Sent: Friday, May 17, 2002 9:47 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - = May > 10-24 > > Ram, > > My comments were intended to try to reconcile the spirit of ForCES = with that > expressed in P1520 (IEEE Programmable Interface for Network Elements). > In P1520, some resource building blocks are identified (e.g. = classifiers, meters, > scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), = from > which services can be built. These allign with the logical functions = identified in the > FE model. We can definitly identify some minimum set of logical = functions necessary > to realize a viable forwarding function in an FE. May be some = langauage can be > added to recommend a minimum set? > > >[RD.Start] Each CE shall have to support one or more functions > >that are related to controlling a particular FE. These functions > >have to identified on a FE by FE basis by the FE/CE managers. > >[RD.End] > > Can we then add a CE Model Requirements section to the draft and > identify CE's requirements there? > > Regards, > Alex. > > Ram Dantu wrote: > > > Alex, > > Please see my comments below. > > > > Regards > > Ram Dantu > > > > -----Original Message----- > > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > > Sent: Wednesday, May 15, 2002 4:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May = 1 > > 0-24 > > > > David, > > > > I am new to this mailing list, though I have been following the = FORCes > > effort for a while > > and I have the comments about the requirements draft. > > > > Section 6 (FE Model Requirements) . Since the logical functions of = the > > FE can be programmed > > or selected by the CE, it also makes sense to allow the = capabilities of > > those logical functions > > to be programmed by the CE. That way, it may not be necessary for = the > > CE to querry for the > > capabilities of the FE before using it (since it already knows this = by > > virtue of being the programmer). > > Can you add language here to clarify this? > > > > [RD.Start] I assume that these queries happen during ForCES = initialization > > as well as due to changes in FE resources. > > [RD.End] > > > > Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also > > specify a minimum set of > > functional/logical blocks every FE must contain? This will be akin = to a > > minimum toolset that > > could be cobbled together to implement any of the main set of = packet > > handling behaviors in a FE. > > [RD.start] Imposing a minimal set may be a controversial subject. = However, > > we can say forwarding function is the minimum function. In the = framework/architecture > > document, we have mentioned some FE and CE functions. > > [RD.End] > > > > Also, are there any unique CE Model Requirements identifiable? > > > > [RD.Start] Each CE shall have to support one or more functions > > that are related to controlling a particular FE. These functions > > have to identified on a FE by FE basis by the FE/CE managers. > > [RD.End] > > > > Regards, > > Alex. > > > > > -----Original Message----- > > > From: Putzolu, David [mailto:david.putzolu@intel.com] > > > Sent: Friday, May 10, 2002 4:14 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - = May > > > 10-24 > > > Importance: High > > > > > > > > > All, > > > > > > This message marks the beginning of a last call > > > for the ForCES requirements document. > > > > > > The last call period begins immediately and lasts > > > until Friday, May 24th, 2002, at midnight GMT. > > > > > > Document URL: > > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem > > ents-03.txt > > > > Thanks, > > David 2002 Message-Id: Date: Thu, 23 May 2002 10:44:02 -0500 From: Alex Audu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May10-24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Ram, Sorry for the delay in responding to your last request. You are right; the ForCES protocol requirement section also implies the responsibilities of CE. However, is it a requirement that CE should handle control and signalling functions? Then we should so state in the document, though it is implied in the draft. Also, can we add language that FoCES protocol should support State Monitoring/Management and Error Reporting? Regards, Alex. Ram Dantu wrote: > Alex, > > In Section 6.5, there is a list of logical functions in FE > (This section defines a minimal set of logical functions > that any FE model MUST support. This minimal set DOES NOT imply > that all FEs must provide this functionality). > We can provide an example on how to achieve a forwarding function with these functions. > I think this can go in the framework document or FE model document. > > Also, I think every ForCES requirement mandates a corresponding > function to be present in the FE and CE. So, I assume > CE should support all ForCES requirements. May be > you can give some examples with reference to some section ? > > Thanks > Ram Dantu > -----Original Message----- > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > Sent: Friday, May 17, 2002 9:47 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > 10-24 > > Ram, > > My comments were intended to try to reconcile the spirit of ForCES with that > expressed in P1520 (IEEE Programmable Interface for Network Elements). > In P1520, some resource building blocks are identified (e.g. classifiers, meters, > scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), from > which services can be built. These allign with the logical functions identified in the > FE model. We can definitly identify some minimum set of logical functions necessary > to realize a viable forwarding function in an FE. May be some langauage can be > added to recommend a minimum set? > > >[RD.Start] Each CE shall have to support one or more functions > >that are related to controlling a particular FE. These functions > >have to identified on a FE by FE basis by the FE/CE managers. > >[RD.End] > > Can we then add a CE Model Requirements section to the draft and > identify CE's requirements there? > > Regards, > Alex. > > Ram Dantu wrote: > > > Alex, > > Please see my comments below. > > > > Regards > > Ram Dantu > > > > -----Original Message----- > > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > > Sent: Wednesday, May 15, 2002 4:41 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 > > 0-24 > > > > David, > > > > I am new to this mailing list, though I have been following the FORCes > > effort for a while > > and I have the comments about the requirements draft. > > > > Section 6 (FE Model Requirements) . Since the logical functions of the > > FE can be programmed > > or selected by the CE, it also makes sense to allow the capabilities of > > those logical functions > > to be programmed by the CE. That way, it may not be necessary for the > > CE to querry for the > > capabilities of the FE before using it (since it already knows this by > > virtue of being the programmer). > > Can you add language here to clarify this? > > > > [RD.Start] I assume that these queries happen during ForCES initialization > > as well as due to changes in FE resources. > > [RD.End] > > > > Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also > > specify a minimum set of > > functional/logical blocks every FE must contain? This will be akin to a > > minimum toolset that > > could be cobbled together to implement any of the main set of packet > > handling behaviors in a FE. > > [RD.start] Imposing a minimal set may be a controversial subject. However, > > we can say forwarding function is the minimum function. In the framework/architecture > > document, we have mentioned some FE and CE functions. > > [RD.End] > > > > Also, are there any unique CE Model Requirements identifiable? > > > > [RD.Start] Each CE shall have to support one or more functions > > that are related to controlling a particular FE. These functions > > have to identified on a FE by FE basis by the FE/CE managers. > > [RD.End] > > > > Regards, > > Alex. > > > > > -----Original Message----- > > > From: Putzolu, David [mailto:david.putzolu@intel.com] > > > Sent: Friday, May 10, 2002 4:14 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > > > 10-24 > > > Importance: High > > > > > > > > > All, > > > > > > This message marks the beginning of a last call > > > for the ForCES requirements document. > > > > > > The last call period begins immediately and lasts > > > until Friday, May 24th, 2002, at midnight GMT. > > > > > > Document URL: > > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem > > ents-03.txt > > > > Thanks, > > David 2002 Message-Id: Date: Thu, 23 May 2002 09:53:34 -0700 From: "Yang, Lily L" Subject: request for WG doc Comments: To: "dro@zurich.ibm.com" , "Putzolu, David" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Patrick, David and all -- On behalf of my co-authors Ram Dantu, Todd Anderson and myself, I would like to request the WG review this framework draft and consider accepting it as a WG document. Lily > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@INTEL.COM] > Sent: Wednesday, May 15, 2002 11:13 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > Hi, all -- > We submitted version 01 of the framework draft last week after a major > rewrite: > * added more description and diagrams to illustrate different physical > configuration examples of ForCES CE/FE. > * added examples of FE topology. > * restructure the text to focus more on ForCES operation > phases (pre- and > post- association, reestablishment, etc.) > * added examples to illustrate the handshake between CE and > FE during these > operational phases. > > please let us know what you think -- are these > examples/diagrams useful? > Have we missed anything important? Any comments on the draft > are welcome! > > Thanks, > Lily > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, May 15, 2002 4:11 AM > Cc: forces@peach.ease.lsoft.com > Subject: I-D ACTION:draft-anderson-forces-arch-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : ForCES Architectural Framework > Author(s) : T. Anderson, L. Yang, R. Dantu > Filename : draft-anderson-forces-arch-01.txt > Pages : 20 > Date : 14-May-02 > > This document defines the architectural framework for ForCES network > elements (NE), associated entities and the interaction among them. > The architecture defined herein is intended to satisfy the > requirements specified in the ForCES requirements draft [FORCES- > REQ]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.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-anderson-forces-arch-01.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-anderson-forces-arch-01.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. > > 2002 Message-Id: Date: Thu, 23 May 2002 09:44:59 -0700 From: "Yang, Lily L" Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Alex -- Thanks for the feedback! Sorry that I didn't repond earlier, I am still digging my way out of my inbox pile ... You are right that in the ideal world, to get the full inter-operabilities of all possible mix and match of CEs and FEs from different vendors, all three communication interfaces have to be standardized. But we live in the real world and it is probably better if we do only one thing at a time. So the one thing we choose to do in ForCES is to separate CE from FE first and standardize the CE-FE interface. This of course is only the first step toward the ideal goal. This would give you inter-operability for the case when CE and FE are from different vendor, but not in the case as you described. Maybe limited, but still very useful as first step. So I think that is ok. We don't intend to solve all problems by one WG. As David Putzolu pointed out, and I agree, that CE-FE is master-slave protocol, while CE-CE and FE-FE are more of peer to peer protocols. Lily > -----Original Message----- > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > Sent: Thursday, May 16, 2002 12:07 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt > > > Hi Lily, > > The current version is much improved. Great job! However, I'd > like to point > out that when you distribute CEs and FEs, you create CE<->CE, CE<->FE > and FE<->FE communication interfaces. ForCES specifies CE<->FE > interface. It will be nice if we also specify CE<->CE > interface (could use > ForCES here too). This becomes improtant when you have different > CE boxes from different vendors controlling different FEs > from also various > vendors in a provider's network, and these boxes have to > inter-operate. > (Sections 4.1 and 4.2) > > Regards, > Alex. > > > "Yang, Lily L" wrote: > > > Hi, all -- > > We submitted version 01 of the framework draft last week > after a major > > rewrite: > > * added more description and diagrams to illustrate > different physical > > configuration examples of ForCES CE/FE. > > * added examples of FE topology. > > * restructure the text to focus more on ForCES operation > phases (pre- and > > post- association, reestablishment, etc.) > > * added examples to illustrate the handshake between CE and > FE during these > > operational phases. > > > > please let us know what you think -- are these > examples/diagrams useful? > > Have we missed anything important? Any comments on the > draft are welcome! > > > > Thanks, > > Lily > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, May 15, 2002 4:11 AM > > Cc: forces@peach.ease.lsoft.com > > Subject: I-D ACTION:draft-anderson-forces-arch-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : ForCES Architectural Framework > > Author(s) : T. Anderson, L. Yang, R. Dantu > > Filename : draft-anderson-forces-arch-01.txt > > Pages : 20 > > Date : 14-May-02 > > > > This document defines the architectural framework for ForCES network > > elements (NE), associated entities and the interaction among them. > > The architecture defined herein is intended to satisfy the > > requirements specified in the ForCES requirements draft [FORCES- > > REQ]. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.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-anderson-forces-arch-01.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-anderson-forces-arch-01.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. > > > > > -------------------------------------------------------------- > ---------- > > > > Subject: > > Date: Wed, 15 May 2002 23:12:54 -0700 > > > > > -------------------------------------------------------------- > ---------- > > > > ATT25595Name: ATT25595 > > Type: unspecified type (application/octet-stream) > > > > Access-Type: anon-ftp > > Document Info: Site: internet-drafts > > Mode: ftp.ietf.org > 2002 Message-Id: Date: Fri, 17 May 2002 15:33:07 -0700 From: "Putzolu, David" Subject: Reminder: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24 MIME-Version: 1.0 Content-Type: text/plain Reminder - the ForCES requirements document started working group last call a week ago and there is one week left in the last call period, which completes on Friday May 24 2002. Cheers, David > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Thursday, May 09, 2002 3:44 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] WG LAST CALL of > draft-ietf-forces-requirements-03.txt - May 10-24 > Importance: High > > > All, > > This message marks the beginning of a last call > for the ForCES requirements document. > > The last call period begins immediately and lasts > until Friday, May 24th, 2002, at midnight GMT. > > Document URL: > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt Thanks, David 2002 Message-Id: Date: Fri, 17 May 2002 10:12:55 -0500 From: Ram Dantu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex, In Section 6.5, there is a list of logical functions in FE=20 (This section defines a minimal set of logical functions=20 that any FE model MUST support. This minimal set DOES NOT imply=20 that all FEs must provide this functionality). We can provide an example on how to achieve a forwarding function with = these functions. I think this can go in the framework document or FE model document. Also, I think every ForCES requirement mandates a corresponding function to be present in the FE and CE. So, I assume CE should support all ForCES requirements. May be you can give some examples with reference to some section ? Thanks Ram Dantu -----Original Message----- From: Alex Audu [mailto:Alex.Audu@alcatel.com] Sent: Friday, May 17, 2002 9:47 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24 Ram, My comments were intended to try to reconcile the spirit of ForCES with = that expressed in P1520 (IEEE Programmable Interface for Network Elements). In P1520, some resource building blocks are identified (e.g. = classifiers, meters, scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), = from which services can be built. These allign with the logical functions = identified in the FE model. We can definitly identify some minimum set of logical = functions necessary to realize a viable forwarding function in an FE. May be some langauage = can be added to recommend a minimum set? >[RD.Start] Each CE shall have to support one or more functions >that are related to controlling a particular FE. These functions >have to identified on a FE by FE basis by the FE/CE managers. >[RD.End] Can we then add a CE Model Requirements section to the draft and identify CE's requirements there? Regards, Alex. Ram Dantu wrote: > Alex, > Please see my comments below. > > Regards > Ram Dantu > > -----Original Message----- > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > Sent: Wednesday, May 15, 2002 4:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 > 0-24 > > David, > > I am new to this mailing list, though I have been following the FORCes > effort for a while > and I have the comments about the requirements draft. > > Section 6 (FE Model Requirements) . Since the logical functions of the > FE can be programmed > or selected by the CE, it also makes sense to allow the capabilities = of > those logical functions > to be programmed by the CE. That way, it may not be necessary for the > CE to querry for the > capabilities of the FE before using it (since it already knows this by > virtue of being the programmer). > Can you add language here to clarify this? > > [RD.Start] I assume that these queries happen during ForCES = initialization > as well as due to changes in FE resources. > [RD.End] > > Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also > specify a minimum set of > functional/logical blocks every FE must contain? This will be akin to = a > minimum toolset that > could be cobbled together to implement any of the main set of packet > handling behaviors in a FE. > [RD.start] Imposing a minimal set may be a controversial subject. = However, > we can say forwarding function is the minimum function. In the = framework/architecture > document, we have mentioned some FE and CE functions. > [RD.End] > > Also, are there any unique CE Model Requirements identifiable? > > [RD.Start] Each CE shall have to support one or more functions > that are related to controlling a particular FE. These functions > have to identified on a FE by FE basis by the FE/CE managers. > [RD.End] > > Regards, > Alex. > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@intel.com] > > Sent: Friday, May 10, 2002 4:14 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > > 10-24 > > Importance: High > > > > > > All, > > > > This message marks the beginning of a last call > > for the ForCES requirements document. > > > > The last call period begins immediately and lasts > > until Friday, May 24th, 2002, at midnight GMT. > > > > Document URL: > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem > ents-03.txt > > Thanks, > David 2002 Message-Id: Date: Fri, 17 May 2002 09:47:21 -0500 From: Alex Audu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ram, My comments were intended to try to reconcile the spirit of ForCES with that expressed in P1520 (IEEE Programmable Interface for Network Elements). In P1520, some resource building blocks are identified (e.g. classifiers, meters, scheduler, queue, marker, dropper, shapper, counter, multiplexor,..), from which services can be built. These allign with the logical functions identified in the FE model. We can definitly identify some minimum set of logical functions necessary to realize a viable forwarding function in an FE. May be some langauage can be added to recommend a minimum set? >[RD.Start] Each CE shall have to support one or more functions >that are related to controlling a particular FE. These functions >have to identified on a FE by FE basis by the FE/CE managers. >[RD.End] Can we then add a CE Model Requirements section to the draft and identify CE's requirements there? Regards, Alex. Ram Dantu wrote: > Alex, > Please see my comments below. > > Regards > Ram Dantu > > -----Original Message----- > From: Alex Audu [mailto:Alex.Audu@alcatel.com] > Sent: Wednesday, May 15, 2002 4:41 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 > 0-24 > > David, > > I am new to this mailing list, though I have been following the FORCes > effort for a while > and I have the comments about the requirements draft. > > Section 6 (FE Model Requirements) . Since the logical functions of the > FE can be programmed > or selected by the CE, it also makes sense to allow the capabilities of > those logical functions > to be programmed by the CE. That way, it may not be necessary for the > CE to querry for the > capabilities of the FE before using it (since it already knows this by > virtue of being the programmer). > Can you add language here to clarify this? > > [RD.Start] I assume that these queries happen during ForCES initialization > as well as due to changes in FE resources. > [RD.End] > > Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also > specify a minimum set of > functional/logical blocks every FE must contain? This will be akin to a > minimum toolset that > could be cobbled together to implement any of the main set of packet > handling behaviors in a FE. > [RD.start] Imposing a minimal set may be a controversial subject. However, > we can say forwarding function is the minimum function. In the framework/architecture > document, we have mentioned some FE and CE functions. > [RD.End] > > Also, are there any unique CE Model Requirements identifiable? > > [RD.Start] Each CE shall have to support one or more functions > that are related to controlling a particular FE. These functions > have to identified on a FE by FE basis by the FE/CE managers. > [RD.End] > > Regards, > Alex. > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@intel.com] > > Sent: Friday, May 10, 2002 4:14 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > > 10-24 > > Importance: High > > > > > > All, > > > > This message marks the beginning of a last call > > for the ForCES requirements document. > > > > The last call period begins immediately and lasts > > until Friday, May 24th, 2002, at midnight GMT. > > > > Document URL: > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem > ents-03.txt > > Thanks, > David 2002 Message-Id: Date: Thu, 16 May 2002 17:11:11 -0700 From: "Putzolu, David" Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt MIME-Version: 1.0 Content-Type: text/plain From: Ram Dantu [mailto:ramd@netrake.com] > [RD.start] Specifying the CE<-->CE interface in ForCES > framework may not be appropriate place. However, we can > mention several other functions of this > interface (other than Section 4.2) in the framework document. > Specifying a detailed specification may be beyond the scope > of ForCES. > Working Group Chair may have some comments on this. > [RD.End] [chair hat on] The problem of solving CE <--> FE communication is already a pretty tough problem, so the CE <--> CE problem is not currently part of our charter. The framework document gives a rough description of that interface and names it (Fr), but we probably should not go a lot further than that. [chair hat off] Personal comments: I don't think CE <--> CE interface (Fr in the framework doc) is same problem as CE <-> FE (Fp). Fr involves issues such as how to distribute or partition calculations such as routing to enable CE scalability, maintaining coherency of state between CEs to prevent FE misconfiguration, CE fault detection and response, sharing decision making procedures, etc. This seems like a peer to peer relationship (although master-slave approaches are also possible). Fp involves communicating forwarding and other tables (resulting from the calculations mentioned above) to FEs and monitoring the statistics and state of FEs. This is a master-slave relationship. I personally think the CE <--> CE problem is a really interesting one, but it seems to me to be different enough that it would probably require its own WG. Cheers, David 2002 Message-Id: Date: Thu, 16 May 2002 15:06:11 -0500 From: Ram Dantu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 0-24 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex, Please see my comments below. Regards Ram Dantu -----Original Message----- From: Alex Audu [mailto:Alex.Audu@alcatel.com] Sent: Wednesday, May 15, 2002 4:41 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 0-24 David, I am new to this mailing list, though I have been following the FORCes effort for a while and I have the comments about the requirements draft. Section 6 (FE Model Requirements) . Since the logical functions of the FE can be programmed or selected by the CE, it also makes sense to allow the capabilities of those logical functions to be programmed by the CE. That way, it may not be necessary for the CE to querry for the capabilities of the FE before using it (since it already knows this by virtue of being the programmer). Can you add language here to clarify this? [RD.Start] I assume that these queries happen during ForCES = initialization as well as due to changes in FE resources. [RD.End] Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also specify a minimum set of functional/logical blocks every FE must contain? This will be akin to a minimum toolset that could be cobbled together to implement any of the main set of packet handling behaviors in a FE. [RD.start] Imposing a minimal set may be a controversial subject. = However, we can say forwarding function is the minimum function. In the = framework/architecture document, we have mentioned some FE and CE functions. [RD.End] Also, are there any unique CE Model Requirements identifiable? [RD.Start] Each CE shall have to support one or more functions that are related to controlling a particular FE. These functions have to identified on a FE by FE basis by the FE/CE managers. [RD.End] Regards, Alex. > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Friday, May 10, 2002 4:14 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > 10-24 > Importance: High > > > All, > > This message marks the beginning of a last call > for the ForCES requirements document. > > The last call period begins immediately and lasts > until Friday, May 24th, 2002, at midnight GMT. > > Document URL: > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem ents-03.txt Thanks, David 2002 Message-Id: Date: Thu, 16 May 2002 14:20:17 -0500 From: Ram Dantu Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex, Thanks for the input. See my comments Regards Ram Dantu -----Original Message----- From: Alex Audu [mailto:Alex.Audu@alcatel.com] Sent: Thursday, May 16, 2002 2:07 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt Hi Lily, The current version is much improved. Great job! However, I'd like to = point out that when you distribute CEs and FEs, you create CE<->CE, CE<->FE and FE<->FE communication interfaces. ForCES specifies CE<->FE interface. It will be nice if we also specify CE<->CE interface (could = use ForCES here too). This becomes improtant when you have different CE boxes from different vendors controlling different FEs from also = various vendors in a provider's network, and these boxes have to inter-operate. (Sections 4.1 and 4.2) [RD.start] Specifying the CE<-->CE interface in ForCES framework may not = be appropriate place. However, we can mention several other functions of = this=20 interface (other than Section 4.2) in the framework document.=20 Specifying a detailed specification may be beyond the scope of ForCES.=20 Working Group Chair may have some comments on this. [RD.End] [] Regards, Alex. "Yang, Lily L" wrote: > Hi, all -- > We submitted version 01 of the framework draft last week after a major > rewrite: > * added more description and diagrams to illustrate different physical > configuration examples of ForCES CE/FE. > * added examples of FE topology. > * restructure the text to focus more on ForCES operation phases (pre- = and > post- association, reestablishment, etc.) > * added examples to illustrate the handshake between CE and FE during = these > operational phases. > > please let us know what you think -- are these examples/diagrams = useful? > Have we missed anything important? Any comments on the draft are = welcome! > > Thanks, > Lily > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, May 15, 2002 4:11 AM > Cc: forces@peach.ease.lsoft.com > Subject: I-D ACTION:draft-anderson-forces-arch-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ForCES Architectural Framework > Author(s) : T. Anderson, L. Yang, R. Dantu > Filename : draft-anderson-forces-arch-01.txt > Pages : 20 > Date : 14-May-02 > > This document defines the architectural framework for ForCES network > elements (NE), associated entities and the interaction among them. > The architecture defined herein is intended to satisfy the > requirements specified in the ForCES requirements draft [FORCES- > REQ]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.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-anderson-forces-arch-01.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-anderson-forces-arch-01.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. > > = ------------------------------------------------------------------------ > > Subject: > Date: Wed, 15 May 2002 23:12:54 -0700 > > = ------------------------------------------------------------------------ > > ATT25595Name: ATT25595 > Type: unspecified type (application/octet-stream) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org 2002 Message-Id: Date: Thu, 16 May 2002 14:06:48 -0500 From: Alex Audu Subject: Re: FW: I-D ACTION:draft-anderson-forces-arch-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Lily, The current version is much improved. Great job! However, I'd like to point out that when you distribute CEs and FEs, you create CE<->CE, CE<->FE and FE<->FE communication interfaces. ForCES specifies CE<->FE interface. It will be nice if we also specify CE<->CE interface (could use ForCES here too). This becomes improtant when you have different CE boxes from different vendors controlling different FEs from also various vendors in a provider's network, and these boxes have to inter-operate. (Sections 4.1 and 4.2) Regards, Alex. "Yang, Lily L" wrote: > Hi, all -- > We submitted version 01 of the framework draft last week after a major > rewrite: > * added more description and diagrams to illustrate different physical > configuration examples of ForCES CE/FE. > * added examples of FE topology. > * restructure the text to focus more on ForCES operation phases (pre- and > post- association, reestablishment, etc.) > * added examples to illustrate the handshake between CE and FE during these > operational phases. > > please let us know what you think -- are these examples/diagrams useful? > Have we missed anything important? Any comments on the draft are welcome! > > Thanks, > Lily > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, May 15, 2002 4:11 AM > Cc: forces@peach.ease.lsoft.com > Subject: I-D ACTION:draft-anderson-forces-arch-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ForCES Architectural Framework > Author(s) : T. Anderson, L. Yang, R. Dantu > Filename : draft-anderson-forces-arch-01.txt > Pages : 20 > Date : 14-May-02 > > This document defines the architectural framework for ForCES network > elements (NE), associated entities and the interaction among them. > The architecture defined herein is intended to satisfy the > requirements specified in the ForCES requirements draft [FORCES- > REQ]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.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-anderson-forces-arch-01.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-anderson-forces-arch-01.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. > > ------------------------------------------------------------------------ > > Subject: > Date: Wed, 15 May 2002 23:12:54 -0700 > > ------------------------------------------------------------------------ > > ATT25595Name: ATT25595 > Type: unspecified type (application/octet-stream) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org 2002 Message-Id: Date: Thu, 16 May 2002 10:13:29 -0500 From: Alex Audu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May10-24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shyam, Once a FE and its controlling CE are distributed in such a way that you need a transport protocol to carry the FORCes protocol messages between them, then you run the risk of exposing that comunication link to security attacks. The risk grows with physical separation between the two. But you are right; if both CE and FE are in the same box, then you may not need an elaborate security scheme (section 7.4). However, there is nothing that says they must be in the same box. Remember, this is a "distributed" architecture. Alex. Shyam prasad wrote: > Alex and Hormuzd, > > Thanks for your responses. Please see my comments below: > > > -----Original Message----- > > From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > > Sent: Thursday, May 16, 2002 3:07 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - > > May 10-24 > > > > > > Thanks for the comments, Alex. > > I'll try to answer the 3rd question below. > > > > Hormuzd > > > > Shyam prasad wrote: > > > > > Hi all, > > > > > > I have a few questions/comments on the draft. I am new to > > this group. > > Sorry > > > if the questions are elementary ones. > > > > > > 1. Are CEs and FEs expected to be part of a single system? > > If the answer > > is > > > yes, isn't implementing security mechanisms such as > > IPSec/IKE for ForCES > > > protocol an overkill? > > > > > > > Section 7.4 (Multihop) states that CE and FE may be > > seperated by more than > > one hop. This may justify use of IPSec/IKE. > > > > The basic doubt still remains. CEs and FEs could be multiple hops away, they > could reside on multiple cards but are they components within a single box?? > > > > > > > 2. The requirements draft does not mention FE redundancy > > and failover. I > > > think FE redundancy support would involve certain amount of > > CE-FE control > > > messaging if CE is viewed as the master and FE, the slave. > > > > > > > See section 7.8 (CE Redundancy or CE Failover). I think this > > section also > > covers > > > > FE redundancy/failover. > > Here's the text under 7.8 : > "The ForCES protocol MUST support mechanisms for CE redundancy or CE > failover. This includes the ability for CEs and FEs to determine > when there is a loss of association between them, ability to restore > association and efficient state (re)synchronization mechanisms. This > also includes the ability to preset the actions an FE will take in > reaction to loss of association to its CE e.g., whether the FE will > continue to forward packets or whether it will halt operations." > > Even if this section is intended to include the FE redundancy requirement, > it's not so obvious. Can it be stated explicitly? Or could you add another > section for FE redundancy? > > > > > > > > > 3. Section 5, point #6 says that an FE MUST be able to > > asynchronously > > inform > > > the CE an increase/decrease in available resources or > > capabilities on the > > > FE. Can this requirement be extended to enable FEs to > > notify failures > > (port > > > failure, internal fault, etc.)? > > > > > [HK] This requirement & section 7 #13 is suppose to cover any failure > > notification > > by the FE. The example talks about change in the number of > > ports (port down > > event). > > Great! But can the verbiage be changed to explicitly state that all failure > notifications are supported and not just "increase/decrease in available > resources". > > Thanks. > Shyam 2002 Message-Id: Date: Thu, 16 May 2002 08:04:42 -0400 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May 10-24 Comments: To: Shyam prasad MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T24gVGh1cnNkYXkgMTYgTWF5IDIwMDIgMDI6MjksIFNoeWFtIHByYXNhZCB3cm90ZToNCg0KPiA+ DQo+ID4gU2VjdGlvbiA3LjQgKE11bHRpaG9wKSAgc3RhdGVzIHRoYXQgQ0UgYW5kIEZFIG1heSBi ZQ0KPiA+IHNlcGVyYXRlZCBieSBtb3JlIHRoYW4NCj4gPiBvbmUgaG9wLiBUaGlzIG1heSBqdXN0 aWZ5IHVzZSBvZiBJUFNlYy9JS0UuDQo+DQo+IFRoZSBiYXNpYyBkb3VidCBzdGlsbCByZW1haW5z LiBDRXMgYW5kIEZFcyBjb3VsZCBiZSBtdWx0aXBsZSBob3BzIGF3YXksDQo+IHRoZXkgY291bGQg cmVzaWRlIG9uIG11bHRpcGxlIGNhcmRzIGJ1dCBhcmUgdGhleSBjb21wb25lbnRzIHdpdGhpbiBh IHNpbmdsZQ0KPiBib3g/Pw0KPg0KDQpJIG1heSBoYXZlIG1pc3VuZGVyc3Rvb2Qgd2hhdCB5b3Ug YXJlIHNheWluZywgYnV0Og0KRG8geW91IHNlZSBhbnl0aGluZyBpbiB0aGUgZHJhZnQgdGhhdCBw cmVjbHVkZXMgYW4gTkUgYmVpbmcgYSBzaW5nbGUgYm94PyANCg0KDQo+ID4gRkUgcmVkdW5kYW5j eS9mYWlsb3Zlci4NCj4NCj4gSGVyZSdzIHRoZSB0ZXh0IHVuZGVyIDcuOCA6DQo+ICJUaGUgRm9y Q0VTIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBtZWNoYW5pc21zIGZvciBDRSByZWR1bmRhbmN5IG9y IENFDQo+ICAgIGZhaWxvdmVyLiBUaGlzIGluY2x1ZGVzIHRoZSBhYmlsaXR5IGZvciBDRXMgYW5k IEZFcyB0byBkZXRlcm1pbmUNCj4gICAgd2hlbiB0aGVyZSBpcyBhIGxvc3Mgb2YgYXNzb2NpYXRp b24gYmV0d2VlbiB0aGVtLCBhYmlsaXR5IHRvIHJlc3RvcmUNCj4gICAgYXNzb2NpYXRpb24gYW5k IGVmZmljaWVudCBzdGF0ZSAocmUpc3luY2hyb25pemF0aW9uIG1lY2hhbmlzbXMuIFRoaXMNCj4g ICAgYWxzbyBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0byBwcmVzZXQgdGhlIGFjdGlvbnMgYW4gRkUg d2lsbCB0YWtlIGluDQo+ICAgIHJlYWN0aW9uIHRvIGxvc3Mgb2YgYXNzb2NpYXRpb24gdG8gaXRz IENFIGUuZy4sIHdoZXRoZXIgdGhlIEZFIHdpbGwNCj4gICAgY29udGludWUgdG8gZm9yd2FyZCBw YWNrZXRzIG9yIHdoZXRoZXIgaXQgd2lsbCBoYWx0IG9wZXJhdGlvbnMuIg0KPg0KPiBFdmVuIGlm IHRoaXMgc2VjdGlvbiBpcyBpbnRlbmRlZCB0byBpbmNsdWRlIHRoZSBGRSByZWR1bmRhbmN5IHJl cXVpcmVtZW50LA0KPiBpdCdzIG5vdCBzbyBvYnZpb3VzLiBDYW4gaXQgYmUgc3RhdGVkIGV4cGxp Y2l0bHk/IE9yIGNvdWxkIHlvdSBhZGQgYW5vdGhlcg0KPiBzZWN0aW9uIGZvciBGRSByZWR1bmRh bmN5Pw0KPg0KDQpTdGF0aW5nIGl0IGV4cGxpY2l0bHkgb3BlbnMgYSBsb3Qgb2YgcmF0IGhvbGVz LCB0aGF0cyB3aHkgaXQgd2FzIHRha2VuIGF3YXkuDQoobG9vayBhdCB0aGUgZWFybGllciBkcmFm dHMpDQpXaGVuIHByb3RvY29sIGRyYWZ0cyBzaG93IHVwLCBpdCB3aWxsIGJlIHN0YXRlZCBleHBs aWNpdGx5Lg0KRG9lcyB0aGUgYWJvdmUgZ2VuZXJpYyB0ZXh0IG1pc3MgYW55IGZhaWxvdmVyIG1l Y2hhbmlzbXM/DQoNCj4gPiBbSEtdIFRoaXMgcmVxdWlyZW1lbnQgJiBzZWN0aW9uIDcgIzEzIGlz IHN1cHBvc2UgdG8gY292ZXIgYW55IGZhaWx1cmUNCj4gPiBub3RpZmljYXRpb24NCj4gPiBieSB0 aGUgRkUuIFRoZSBleGFtcGxlIHRhbGtzIGFib3V0IGNoYW5nZSBpbiB0aGUgbnVtYmVyIG9mDQo+ ID4gcG9ydHMgKHBvcnQgZG93bg0KPiA+IGV2ZW50KS4NCj4NCj4gR3JlYXQhIEJ1dCBjYW4gdGhl IHZlcmJpYWdlIGJlIGNoYW5nZWQgdG8gZXhwbGljaXRseSBzdGF0ZSB0aGF0IGFsbCBmYWlsdXJl DQo+IG5vdGlmaWNhdGlvbnMgYXJlIHN1cHBvcnRlZCBhbmQgbm90IGp1c3QgImluY3JlYXNlL2Rl Y3JlYXNlIGluIGF2YWlsYWJsZQ0KPiByZXNvdXJjZXMiLg0KPg0KDQpDYW4geW91IGJlIG1vcmUg c3BlY2lmaWM/IA0KDQpjaGVlcnMsDQpqYW1hbA0K 2002 Message-Id: Date: Thu, 16 May 2002 02:29:11 -0400 From: Shyam prasad Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May 10-24 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Alex and Hormuzd, Thanks for your responses. Please see my comments below: > -----Original Message----- > From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > Sent: Thursday, May 16, 2002 3:07 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - > May 10-24 > > > Thanks for the comments, Alex. > I'll try to answer the 3rd question below. > > Hormuzd > > Shyam prasad wrote: > > > Hi all, > > > > I have a few questions/comments on the draft. I am new to > this group. > Sorry > > if the questions are elementary ones. > > > > 1. Are CEs and FEs expected to be part of a single system? > If the answer > is > > yes, isn't implementing security mechanisms such as > IPSec/IKE for ForCES > > protocol an overkill? > > > > Section 7.4 (Multihop) states that CE and FE may be > seperated by more than > one hop. This may justify use of IPSec/IKE. > The basic doubt still remains. CEs and FEs could be multiple hops away, they could reside on multiple cards but are they components within a single box?? > > > > 2. The requirements draft does not mention FE redundancy > and failover. I > > think FE redundancy support would involve certain amount of > CE-FE control > > messaging if CE is viewed as the master and FE, the slave. > > > > See section 7.8 (CE Redundancy or CE Failover). I think this > section also > covers > > FE redundancy/failover. Here's the text under 7.8 : "The ForCES protocol MUST support mechanisms for CE redundancy or CE failover. This includes the ability for CEs and FEs to determine when there is a loss of association between them, ability to restore association and efficient state (re)synchronization mechanisms. This also includes the ability to preset the actions an FE will take in reaction to loss of association to its CE e.g., whether the FE will continue to forward packets or whether it will halt operations." Even if this section is intended to include the FE redundancy requirement, it's not so obvious. Can it be stated explicitly? Or could you add another section for FE redundancy? > > > > > 3. Section 5, point #6 says that an FE MUST be able to > asynchronously > inform > > the CE an increase/decrease in available resources or > capabilities on the > > FE. Can this requirement be extended to enable FEs to > notify failures > (port > > failure, internal fault, etc.)? > > > [HK] This requirement & section 7 #13 is suppose to cover any failure > notification > by the FE. The example talks about change in the number of > ports (port down > event). Great! But can the verbiage be changed to explicitly state that all failure notifications are supported and not just "increase/decrease in available resources". Thanks. Shyam 2002 Message-Id: Date: Wed, 15 May 2002 23:12:51 -0700 From: "Yang, Lily L" Subject: FW: I-D ACTION:draft-anderson-forces-arch-01.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1FCA0.B57C3E70" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1FCA0.B57C3E70 Content-Type: text/plain; charset="iso-8859-1" Hi, all -- We submitted version 01 of the framework draft last week after a major rewrite: * added more description and diagrams to illustrate different physical configuration examples of ForCES CE/FE. * added examples of FE topology. * restructure the text to focus more on ForCES operation phases (pre- and post- association, reestablishment, etc.) * added examples to illustrate the handshake between CE and FE during these operational phases. please let us know what you think -- are these examples/diagrams useful? Have we missed anything important? Any comments on the draft are welcome! Thanks, Lily -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, May 15, 2002 4:11 AM Cc: forces@peach.ease.lsoft.com Subject: I-D ACTION:draft-anderson-forces-arch-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForCES Architectural Framework Author(s) : T. Anderson, L. Yang, R. Dantu Filename : draft-anderson-forces-arch-01.txt Pages : 20 Date : 14-May-02 This document defines the architectural framework for ForCES network elements (NE), associated entities and the interaction among them. The architecture defined herein is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.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-anderson-forces-arch-01.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-anderson-forces-arch-01.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_000_01C1FCA0.B57C3E70 Content-Type: message/rfc822 To: Subject: Date: Wed, 15 May 2002 23:12:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1FCA0.B57C3E70" ------_=_NextPart_002_01C1FCA0.B57C3E70 Content-Type: text/plain ------_=_NextPart_002_01C1FCA0.B57C3E70 Content-Type: application/octet-stream; name="ATT25595" Content-Disposition: attachment; filename="ATT25595" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020514141822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-anderson-forces-arch-01.txt ------_=_NextPart_002_01C1FCA0.B57C3E70 Content-Type: message/external-body; site="internet-drafts"; dir="draft-anderson-forces-arch-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1FCA0.B57C3E70-- ------_=_NextPart_000_01C1FCA0.B57C3E70-- 2002 Message-Id: Date: Wed, 15 May 2002 16:40:36 -0500 From: Alex Audu Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 0-24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, I am new to this mailing list, though I have been following the FORCes effort for a while and I have the comments about the requirements draft. Section 6 (FE Model Requirements) . Since the logical functions of the FE can be programmed or selected by the CE, it also makes sense to allow the capabilities of those logical functions to be programmed by the CE. That way, it may not be necessary for the CE to querry for the capabilities of the FE before using it (since it already knows this by virtue of being the programmer). Can you add language here to clarify this? Section 6.5 (Minimal Set of Logical Functions). Shouldn't we also specify a minimum set of functional/logical blocks every FE must contain? This will be akin to a minimum toolset that could be cobbled together to implement any of the main set of packet handling behaviors in a FE. Also, are there any unique CE Model Requirements identifiable? Regards, Alex. > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Friday, May 10, 2002 4:14 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > 10-24 > Importance: High > > > All, > > This message marks the beginning of a last call > for the ForCES requirements document. > > The last call period begins immediately and lasts > until Friday, May 24th, 2002, at midnight GMT. > > Document URL: > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem ents-03.txt Thanks, David 2002 Message-Id: Date: Wed, 15 May 2002 16:08:00 -0500 From: Alex Audu Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shyam, See below for comments that may answer some of your questions. Regards, Alex. Shyam prasad wrote: > Hi all, > > I have a few questions/comments on the draft. I am new to this group. Sorry > if the questions are elementary ones. > > 1. Are CEs and FEs expected to be part of a single system? If the answer is > yes, isn't implementing security mechanisms such as IPSec/IKE for ForCES > protocol an overkill? > Section 7.4 (Multihop) states that CE and FE may be seperated by more than one hop. This may justify use of IPSec/IKE. > > 2. The requirements draft does not mention FE redundancy and failover. I > think FE redundancy support would involve certain amount of CE-FE control > messaging if CE is viewed as the master and FE, the slave. > See section 7.8 (CE Redundancy or CE Failover). I think this section also covers FE redundancy/failover. > > 3. Section 5, point #6 says that an FE MUST be able to asynchronously inform > the CE an increase/decrease in available resources or capabilities on the > FE. Can this requirement be extended to enable FEs to notify failures (port > failure, internal fault, etc.)? > > Thanks. > Shyam > > > -----Original Message----- > > From: Putzolu, David [mailto:david.putzolu@intel.com] > > Sent: Friday, May 10, 2002 4:14 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > > 10-24 > > Importance: High > > > > > > All, > > > > This message marks the beginning of a last call > > for the ForCES requirements document. > > > > The last call period begins immediately and lasts > > until Friday, May 24th, 2002, at midnight GMT. > > > > Document URL: > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem > ents-03.txt > > Thanks, > David 2002 Message-Id: Date: Wed, 15 May 2002 14:37:00 -0700 From: "Khosravi, Hormuzd M" Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.tx t - May 10-24 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks for the comments, Alex. I'll try to answer the 3rd question below. Hormuzd Shyam prasad wrote: > Hi all, > > I have a few questions/comments on the draft. I am new to this group. Sorry > if the questions are elementary ones. > > 1. Are CEs and FEs expected to be part of a single system? If the answer is > yes, isn't implementing security mechanisms such as IPSec/IKE for ForCES > protocol an overkill? > Section 7.4 (Multihop) states that CE and FE may be seperated by more than one hop. This may justify use of IPSec/IKE. > > 2. The requirements draft does not mention FE redundancy and failover. I > think FE redundancy support would involve certain amount of CE-FE control > messaging if CE is viewed as the master and FE, the slave. > See section 7.8 (CE Redundancy or CE Failover). I think this section also covers FE redundancy/failover. > > 3. Section 5, point #6 says that an FE MUST be able to asynchronously inform > the CE an increase/decrease in available resources or capabilities on the > FE. Can this requirement be extended to enable FEs to notify failures (port > failure, internal fault, etc.)? > [HK] This requirement & section 7 #13 is suppose to cover any failure notification by the FE. The example talks about change in the number of ports (port down event). > Thanks. > Shyam > 2002 Message-Id: Date: Wed, 15 May 2002 07:11:16 -0400 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-anderson-forces-arch-01.txt Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForCES Architectural Framework Author(s) : T. Anderson, L. Yang, R. Dantu Filename : draft-anderson-forces-arch-01.txt Pages : 20 Date : 14-May-02 This document defines the architectural framework for ForCES network elements (NE), associated entities and the interaction among them. The architecture defined herein is intended to satisfy the requirements specified in the ForCES requirements draft [FORCES- REQ]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anderson-forces-arch-01.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-anderson-forces-arch-01.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-anderson-forces-arch-01.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: <20020514141822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-anderson-forces-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-anderson-forces-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020514141822.I-D@ietf.org> --OtherAccess-- --NextPart-- 2002 Message-Id: Date: Wed, 15 May 2002 05:27:31 -0400 From: Shyam prasad Subject: Re: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 1 0-24 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, I have a few questions/comments on the draft. I am new to this group. Sorry if the questions are elementary ones. 1. Are CEs and FEs expected to be part of a single system? If the answer is yes, isn't implementing security mechanisms such as IPSec/IKE for ForCES protocol an overkill? 2. The requirements draft does not mention FE redundancy and failover. I think FE redundancy support would involve certain amount of CE-FE control messaging if CE is viewed as the master and FE, the slave. 3. Section 5, point #6 says that an FE MUST be able to asynchronously inform the CE an increase/decrease in available resources or capabilities on the FE. Can this requirement be extended to enable FEs to notify failures (port failure, internal fault, etc.)? Thanks. Shyam > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Friday, May 10, 2002 4:14 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May > 10-24 > Importance: High > > > All, > > This message marks the beginning of a last call > for the ForCES requirements document. > > The last call period begins immediately and lasts > until Friday, May 24th, 2002, at midnight GMT. > > Document URL: > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirem ents-03.txt Thanks, David 2002 Message-Id: Date: Thu, 9 May 2002 15:44:12 -0700 From: "Putzolu, David" Subject: WG LAST CALL of draft-ietf-forces-requirements-03.txt - May 10-24 MIME-Version: 1.0 Content-Type: text/plain All, This message marks the beginning of a last call for the ForCES requirements document. The last call period begins immediately and lasts until Friday, May 24th, 2002, at midnight GMT. Document URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt Thanks, David 2002 Message-Id: Date: Tue, 7 May 2002 09:15:35 -0700 From: "Putzolu, David" Subject: FW: IEEE T-SMC CFP: Technologies that promote computational intel ligence, openness and programmability in networks and Internet services MIME-Version: 1.0 Content-Type: text/plain Forwarded as potentially relevant to ForCES. Cheers, David > -----Original Message----- > From: S. Karnouskos [mailto:karnouskos@fokus.fhg.de] > Sent: Tuesday, May 07, 2002 3:49 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: IEEE T-SMC CFP: Technologies that promote > computational intelligence, openness and programmability in > networks and Internet services > > > > Dear Ladies and Gentlemen, > > This might be of interest to ForCES WG members. > We are looking for papers for the following CFP. > Please feel free to further forward it to people you think > might be interested in it. > > Best Regards, > Stamatis Karnouskos > > > -------------------------------------------------------------- > -------------- > > > IEEE - Transactions on Systems, Man and Cybernetics > > Call for Papers - Special Issue on > > Technologies that promote computational intelligence, > openness and > programmability in networks and Internet services > > > > > Guest Editors: > > * W. Pedrycz (Univ. of Alberta, Canada), > * A. Vasilakos (Hellenic Aerospace Industry,S.A.), > * S. Karnouskos (Fraunhofer-FOKUS, Germany) > > Publication: Winter 2002 > > The Internet has witnessed the last years a rapid increase in > its popularity, by offering new services to its users. > However the increased complexity of the systems, the growing > needs for flexibility, fault-tolerance, higher quality of > service, interoperability, security, reduced time-to-market > service introduction and personalization, demand the > development of sophisticated technologies that are capable of > dealing effectively with these challenges. > > Active and programmable networking aims at easing the > introduction of new network services by adding dynamic > programmability to network devices and making aspects of the > programmability accessible to third-party vendors and users > via open interfaces. Open and programmable network elements > are redefining network software architectures and move > control and management systems away from traditional > closed/rigid solutions. > > Computational Intelligence (CI) is viewed as a synergy of > technologies of granular computing (especially fuzzy sets), > neural networks and evolutionary computing has become an > ideal design vehicle supporting the design of intelligent > systems. In this capacity, the role of CI in the development > of the sophisticated network architectures is profound. The > main objective of this special issue of the IEEE T-SMC > Journal is to act as a channel that brings the ideas of CI to > the network area in a systematic, coherent and comprehensive fashion. > > Authors are encouraged to submit high-quality original papers > dealing with various theoretical and practical issues dealing > with Computational Intelligence, active networking, > intelligent mobile agents, > openness/portability/interoperability of services, middleware > for intelligent service creation, deployment and management > of new network applications etc. > > > Within the context of this special issue, topics of > particular interest include but are not limited to: > > * Active and Programmable Networks > * Service creation platforms and enabling technologies > * Telecommunication Network Architectures > * Communications Security, Privacy and Manageability > * Integrated Services > * Dynamic, data-driven application systems > * Service dissemination and discovery protocols > * Programming paradigms, applications, and requirements for > active grids > * Nomadic User Support and management > * Web based systems and services > * Global Service Portability > * Emerging Technologies and directions > * Internet & Telecom applications and services > * Neural Networks > * Fuzzy Logic > * Genetic Algorithms & Programming > * Data Mining Techniques > * Adaptive Computing Systems > * Knowledge Based Systems > * Hybrid Intelligent Systems > > IMPORTANT DATES > > Submission: 1st July 2002 > Acceptance decision: 30th Oct 2002 > Final paper due: 31st Dec 2002 > Publication date: Winter 2002 > > SUBMISSION GUIDELINES > > Authors are invited to submit full papers, following the > templates available from the publisher in electronic form > (PDF preferred) to the Guest Editor at the following address: > > Prof. Witold Pedrycz > Department of Electrical & Computer Engineering > University of Alberta > Edmonton T6R 2G7 Canada > > Or to send an electronic copy via e-mail or the URL from > where the file can be downloaded, to any of the guest editors: > > * W. Pedrycz pedrycz@ee.ualberta.ca, > * A. Vasilakos vasilako@ath.forthnet.gr, > * S. Karnouskos karnouskos@fokus.fhg.de. > > Please include keywords identifying the main topic of your > paper. Full details of submission or further information are > available from the journal's web site > http://www.isye.gatech.edu/ieee-smc. > > This CFP is also > available in HTML, PDF and plain > text format from > http://www.fokus.fhg.de/usr/karnouskos/private> /cfp/smc/ > > > > > > ---------------------------------------------------------- > Stamatis Karnouskos - Fraunhofer FOKUS > Research Institute for Open Communication Systems > mailto:karnouskos@fokus.fhg.de http://www.fokus.fhg.de Phone: +49-30-34637172 FAX: +49-30-34638172 ---------------------------------------------------------- 2002 Message-Id: Date: Mon, 6 May 2002 10:23:51 -0700 From: "Putzolu, David" Subject: URL weirdness (was: RE: [FORCES] Requirements Issue Summary: High Availability) MIME-Version: 1.0 Content-Type: text/plain All, I just learned of some weirdness with this email. If you are using Microsoft OutlookXP and WindowsXP, and you click on the lsoft URLs below, you will get an error. However, if you copy the URL, then paste it into your browser, the URL works fine. Can't explain it, but if anyone is scratching their heads trying to get to those URLs, just cut-and-paste the URL into your browser and it should work. Cheers, David -----Original Message----- From: Putzolu, David [mailto:david.putzolu@intel.com] Sent: Monday, May 06, 2002 9:15 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Requirements Issue Summary: High Availability All, The topic of high availability has been discussed over the last few weeks on the mailing list and by the requirements design team. URLs: http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0204&L=forces#4 http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0203&L=forces#5 The design team has responded in version 03 of the requirements by removing the vague wording and replacing it with text about CE redundancy and failover support. Section 5 item 7 and section 7 of the requirements where revved and this rev was uploaded last week. These changes reflect the consensus of the design team and the discussions on the list, so I am moving it to "closed" status on the web page barring any last comments. URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt Cheers, David 2002 Message-Id: Date: Mon, 6 May 2002 09:14:38 -0700 From: "Putzolu, David" Subject: Requirements Issue Summary: High Availability MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F519.1EB01BD0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F519.1EB01BD0 Content-Type: text/plain All, The topic of high availability has been discussed over the last few weeks on the mailing list and by the requirements design team. URLs: http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0204&L=forces#4 http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0203&L=forces#5 The design team has responded in version 03 of the requirements by removing the vague wording and replacing it with text about CE redundancy and failover support. Section 5 item 7 and section 7 of the requirements where revved and this rev was uploaded last week. These changes reflect the consensus of the design team and the discussions on the list, so I am moving it to "closed" status on the web page barring any last comments. URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.txt Cheers, David ------_=_NextPart_001_01C1F519.1EB01BD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Requirements Issue Summary: High Availability

All,

The topic of high availability has = been discussed over the
last few weeks on the mailing list = and by the requirements
design team. URLs:

http://peach.ease.lsoft.com/scripts/wa.exe?A1=3Dind0204&a= mp;L=3Dforces#4
http://peach.ease.lsoft.com/scripts/wa.exe?A1=3Dind0203&a= mp;L=3Dforces#5

The design team has responded in = version 03 of the
requirements by removing the vague = wording and replacing it
with text about CE redundancy and = failover support. 
Section 5 item 7 and section 7 of the = requirements where
revved and this rev was uploaded last = week.  These changes
reflect the consensus of the design = team and the
discussions on the list, so I am = moving it to "closed" status
on the web page barring any last = comments. URL:

http://www.ietf.org/internet-drafts/draft-ietf-forces-req= uirements-03.txt

Cheers,
David

------_=_NextPart_001_01C1F519.1EB01BD0-- 2002 Message-Id: Date: Mon, 6 May 2002 09:12:16 -0700 From: "Putzolu, David" Subject: ForCES Supplemental Home Page Revamped MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F518.CA395620" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F518.CA395620 Content-Type: text/plain All, The ForCES supplemental home page has been revamped to include significantly more information about the state of various documents related to ForCES. I will be updating this page regularly with a list of working open issues and draft status. URL: http://www.sstanamera.com/~forces/index.html This page is also now linked to by the IETF ForCES charter webpage. Cheers, David Putzolu ------_=_NextPart_001_01C1F518.CA395620 Content-Type: text/html Content-Transfer-Encoding: quoted-printable ForCES Supplemental Home Page Revamped

All,

The ForCES supplemental home page has = been revamped to include
significantly more information about = the state of various documents
related to ForCES.  I will be = updating this page regularly with a list of
working open issues and draft = status.  URL:

http://www.sstanamera.com/~forces/index.html

This page is also now linked to by the = IETF ForCES charter webpage.

Cheers,
David Putzolu

------_=_NextPart_001_01C1F518.CA395620-- 2002 Message-Id: Date: Thu, 2 May 2002 08:57:43 -0400 From: Vip Sharma Subject: Re: I-D ACTION:draft-ietf-forces-requirements-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hormuzd, I agree with your summarry of the reqmnt. Draft... That it is ready for last call.. vip -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Khosravi, Hormuzd M Sent: Wednesday, May 01, 2002 8:40 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: I-D ACTION:draft-ietf-forces-requirements-03.txt The design team has put together the new revision of the Requirements draft. We have tried to incorporate all the comments that we received for the last version. I think the draft is in good shape and would like to last call it. Any comments ? Hormuzd -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 30, 2002 4:15 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] I-D ACTION:draft-ietf-forces-requirements-03.txt 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 : Requirements for Separation of IP Control and Forwarding Author(s) : T. Anderson et al. Filename : draft-ietf-forces-requirements-03.txt Pages : 15 Date : 29-Apr-02 This document introduces the ForCES architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.tx t 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-requirements-03.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-requirements-03.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. 2002 Message-Id: Date: Wed, 1 May 2002 17:39:59 -0700 From: "Khosravi, Hormuzd M" Subject: Re: I-D ACTION:draft-ietf-forces-requirements-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The design team has put together the new revision of the Requirements draft. We have tried to incorporate all the comments that we received for the last version. I think the draft is in good shape and would like to last call it. Any comments ? Hormuzd -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 30, 2002 4:15 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] I-D ACTION:draft-ietf-forces-requirements-03.txt 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 : Requirements for Separation of IP Control and Forwarding Author(s) : T. Anderson et al. Filename : draft-ietf-forces-requirements-03.txt Pages : 15 Date : 29-Apr-02 This document introduces the ForCES architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-03.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-requirements-03.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-requirements-03.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.