2004 Message-Id: Date: Fri, 27 Feb 2004 14:27:17 -0500 From: Zsolt Haraszti Organization: Ericsson IPI Subject: FACT draft truncated on ForCES website Comments: To: David Putzolu , Patrick Droz Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit David, Patrick, The FACT protocol I-D (ver 06) is corrupted at the ForCES website. The document ends at page 7. I presume this is the current draft version. /zsolt 2004 Message-Id: Date: Fri, 27 Feb 2004 11:09:11 -0500 From: Zsolt Haraszti Subject: Re: ForCES model Comments: To: anurag.bhargava@ericsson.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Anurag, It is a default behavior of any LFB to pass all "un-interesting" metadata transparently. Any metadata that is not explicitly or implicitly used (read/produced) by the LFB fall into this category. This should be in the draft somewhere. Some implementations will have inherent physical limitations and will not be able to provide this default behavior. We are currently looking into if and how such limitations should be expressed by via the model. Suggestions are welcome. /zsolt Anurag Bhargava wrote: > I see your point. But if we look at it from the LFB's perspective. For > example, LFB A expects metadata 1 and at the same time also needs to be > passed on or produced so that it can be consumed at a later stage, having > this information will be helpful. I don't know the topology but yet know > that it will be used by later LFBs. > > For example, > Meter LFB will use the frame length and also the Queue LFB. So, when we > define Meter LFB, atleast in that definition, we can say that length > metadata should be passed by this Meter LFB. But if the model doesn't > provide this information, how will each LFB know. > > -- > anurag > > On Fri, 27 Feb 2004, Yang, Lily L wrote: > > >>That seems impossible to do -- because the metadata that an LFB passes >>transparently really depend on the other LFBS in the datapath, that is, >>the LFBS before and after this LFB in question. So the LFB itself does >>not have that knowledge at all prior to run time. But that is the kind >>of information the LFB itself (or the CE) can infer at run time, once >>the LFB topology is known. >> >>For example, if LFB A, B, C (in that order) form the datapath, B has to >>pass whatever metadata that is produced by A and expected by C. >> >>Right? >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Anurag Bhargava >>Sent: Friday, February 27, 2004 7:31 AM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: ForCES model >> >>Hello, >> >> I see that we have metadata Expected and metadata Produced in the >>schema >>in draft-ietf-forces-model-02.txt. >> >> I was wondering if we should also add an additional information which >>will give an idea that the metadata should be passed transparently. It >>will still be part of the above classes but will provide the LFB >>implementor >>that this metadata should be passed unmodified. This will impose the >>needed >>restricion. And in my mind could be part of the standard FE model >> >>Any comments.. >> >>-- >>anurag >> > > > 2004 Message-Id: Date: Fri, 27 Feb 2004 10:52:10 -0500 From: Anurag Bhargava Subject: Re: ForCES model Comments: To: "Yang, Lily L" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I see your point. But if we look at it from the LFB's perspective. For example, LFB A expects metadata 1 and at the same time also needs to be passed on or produced so that it can be consumed at a later stage, having this information will be helpful. I don't know the topology but yet know that it will be used by later LFBs. For example, Meter LFB will use the frame length and also the Queue LFB. So, when we define Meter LFB, atleast in that definition, we can say that length metadata should be passed by this Meter LFB. But if the model doesn't provide this information, how will each LFB know. -- anurag On Fri, 27 Feb 2004, Yang, Lily L wrote: > That seems impossible to do -- because the metadata that an LFB passes > transparently really depend on the other LFBS in the datapath, that is, > the LFBS before and after this LFB in question. So the LFB itself does > not have that knowledge at all prior to run time. But that is the kind > of information the LFB itself (or the CE) can infer at run time, once > the LFB topology is known. > > For example, if LFB A, B, C (in that order) form the datapath, B has to > pass whatever metadata that is produced by A and expected by C. > > Right? > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Anurag Bhargava > Sent: Friday, February 27, 2004 7:31 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: ForCES model > > Hello, > > I see that we have metadata Expected and metadata Produced in the > schema > in draft-ietf-forces-model-02.txt. > > I was wondering if we should also add an additional information which > will give an idea that the metadata should be passed transparently. It > will still be part of the above classes but will provide the LFB > implementor > that this metadata should be passed unmodified. This will impose the > needed > restricion. And in my mind could be part of the standard FE model > > Any comments.. > > -- > anurag > 2004 Message-Id: Date: Fri, 27 Feb 2004 10:30:37 -0500 From: Anurag Bhargava Subject: ForCES model Comments: To: Zsolt.Haraszti@ericsson.com, steven.blake@ericsson.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I see that we have metadata Expected and metadata Produced in the schema in draft-ietf-forces-model-02.txt. I was wondering if we should also add an additional information which will give an idea that the metadata should be passed transparently. It will still be part of the above classes but will provide the LFB implementor that this metadata should be passed unmodified. This will impose the needed restricion. And in my mind could be part of the standard FE model Any comments.. -- anurag 2004 Message-Id: Date: Fri, 27 Feb 2004 09:10:15 -0800 From: "Cain, Gamil" Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt Comments: To: "Yang, Lily L" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lily et all, Here's my feedback on the latest FE model: - Section 2.4, first sentence is a bit confusing and should probably be broken into two sentences. - Section 3.2.3, the first paragraph mentions "frame type". I would suggest staying consistent with terms. Either use "frame type" or "packet type" but not both. - Last paragraph before section 3.2.4.3, is this "harmonization" out of scope for ForCES? Does ForCES assume this is something that will be taken up by some external organization (i.e. NPF)? Section 4.5.3 and 4.5.4 should probably be swapped in the document. Section 4.5.3 makes use of the element before it's formally described in section 4.5.4 Section 4.5.6: The augmentation concept could be described a bit clearer. What advantage does this concept have over using the schema elements already defined (, , , etc.)? Section 4.7, last paragraph: How useful is a schema for an LFB class that only contains the name, synopsis, and version? It might be good to add some text to this paragraph saying that it is expected that a class definition will have more then just these three elements. Section 4.7.2: Third paragraph is a repeat of the last sentence of the first paragraph. Section 4.7.3: Does the LFB class need to also specify what metadata it passes through? I would think not, but it might be good to add a paragraph describing the LFB classes behavior wrt pass-through metadata. Section 4.7.5: Is there (or should there be) a requirement for an instance of an LFB class to specify capabilities for all attributes it supports? If not, should there at least be some guidance in this document that describes what types of capability information should be exposed? Section 6.1: What is meant by the static attribute "port type"? Examples would be helpful. Section 6.1: In some devices, the physical port link speed is a configurable, as opposed to static, attribute (e.g. a framer that can do DS3 and OC-3 or OC-12). How would one go about modeling such a device, using the current Port LFB class definition? Or would you not model such a device as a single LFB, but rather as multiple LFBs that can be enabled/disabled (e.g. a DS3 Port LFB, a OC-3 Port LFB, etc. all managing the same physical device)? Section 8.6, 2nd paragraph: There's a reference to a section 9.5 which does not exist. Regards, Gamil Cain Software Architect Intel Research & Development 916.356.9153 mailto:gamil.cain@intel.com =20 >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L >Sent: Tuesday, February 17, 2004 8:49 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt > >Hi, all -- > >The FE model design team just published v02 of the FE model document. >The entire document has been edited throughout, but most notably some >major progress has been reflected in this revision: >1) 3.2.4 "metadata" section is completely rewritten, with the metadata >model that was published to this list by Zsolt a few weeks ago. We >believe most comments we've received so far are addressed in this >revision. >2) Section 4 "model and schema for LFB classes" is rewritten, with >formal XML schema specified at the end of the section. >3) Section 5 "FE Attributes and Capabilities" now is completed with also >formal XML schema specification, that was also published to the list a >few weeks ago by Joel. >4) The old section 6 in v01 was a place holder for LFB topology and now >gone because the content of LFB topology is merged into "FE attributes >and Capabilities" in Section 5. The comments we received are also >incorporated into this new revision. >5) Section 6 "LFB Class Library" (old section 7 in v01) is also revised >significantly with now 18 LFB classes that include the most commonly >found functions for IP processing, forwarding and QoS. >6) Section 7 "satisfying the requirements" (old section 8 in v01) is >also revised considerably. > >With this revision, the major pieces that make up the FE model are now >in place, with the exception of a few minor features here and there >(e.g., class inheritance is not fully flushed out in the LFB schema). We >hope this revision would provide timely input into the protocol >development. In the meantime, we hope the WG and especially the protocol >designers would take time to review and provide feedback on the FE >model, so that we can refine it to the satisfaction of the WG in the >next few months. > > >Thank you all, > >Lily > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of >Internet-Drafts@ietf.org >Sent: Tuesday, February 17, 2004 7:32 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: I-D ACTION:draft-ietf-forces-model-02.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 : ForCES Forwarding Element Functional Model > Author(s) : L. Yang > Filename : draft-ietf-forces-model-02.txt > Pages : 101 > Date : 2004-2-17 > >This document defines the forwarding element (FE) model used in the >Forwarding and Control Plane Separation (ForCES) protocol. The >model represents the capabilities, state and configuration of >forwarding elements within the context of the ForCES protocol, so >that control elements (CEs) can control the FEs accordingly. More >specifically, the model describes the logical functions that are >present in an FE, what capabilities these functions support, and >how these functions are or can be interconnected. This FE model is >intended to satisfy the model requirements specified in the ForCES >requirements draft [1]. A list of the basic logical functional >blocks (LFBs) is also defined in the LFB class library to aid the >effort in defining individual LFBs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.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-model-02.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-model-02.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. 2004 Message-Id: Date: Fri, 27 Feb 2004 07:38:43 -0800 From: "Yang, Lily L" Subject: Re: ForCES model Comments: To: anurag.bhargava@ericsson.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That seems impossible to do -- because the metadata that an LFB passes transparently really depend on the other LFBS in the datapath, that is, the LFBS before and after this LFB in question. So the LFB itself does not have that knowledge at all prior to run time. But that is the kind of information the LFB itself (or the CE) can infer at run time, once the LFB topology is known.=20 For example, if LFB A, B, C (in that order) form the datapath, B has to pass whatever metadata that is produced by A and expected by C.=20 Right?=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Anurag Bhargava Sent: Friday, February 27, 2004 7:31 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: ForCES model Hello, I see that we have metadata Expected and metadata Produced in the schema in draft-ietf-forces-model-02.txt. I was wondering if we should also add an additional information which will give an idea that the metadata should be passed transparently. It will still be part of the above classes but will provide the LFB implementor that this metadata should be passed unmodified. This will impose the needed restricion. And in my mind could be part of the standard FE model Any comments.. -- anurag 2004 Message-Id: Date: Mon, 23 Feb 2004 15:29:33 -0800 From: "Putzolu, David" Subject: No bonus Interim Meeting for ForCES @ IETF 59 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, As it turns out, of the people attending the Korea IETF, arrival and other schedules are varied enough that getting=20 sufficient ForCES participants together on Sunday for=20 productive work is not feasible. As such, there will be no *additional interim* ForCES meeting @ IETF 59. However, I encourage all attendees to try to get together at least at the reception to work on making protocol progress. That being said, ForCES *IS* scheduled for Tuesday, March 2 @ 0900, and that meeting will be held. Please plan=20 on attending! -David 2004 Message-Id: Date: Thu, 19 Feb 2004 09:09:09 -0800 From: "Putzolu, David" Subject: Announcement: Open design team formed to examine possibility of merged protocol proposal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, In order to make progress on the protocol=20 selection process, Patrick & I would like=20 to examine whether a common protocol proposal is feasible. More specifically, we would like to see whether a merged proposal, based on the best aspects of each of the currently existing ForCES protocol proposals, can be made. In order to do this we are forming a short- lived design team that is chartered with=20 examining the aspects of the currently=20 existing protocol proposals, seeing what=20 common ground there is, and determining=20 whether the common ground is sufficient=20 for coming up with a single merged proposal. This design team is tasked with coming up with a report to the working group after one month's time, by March 20, 2004. =20 Patrick & I will be participating in the=20 design team to help make sure that good=20 progress is made. =20 Membership in this design team is open and we expect work to begin immediately. If you are interested in participating please email me or Patrick. =20 -David & Patrick 2004 Message-Id: Date: Tue, 17 Feb 2004 10:31:36 -0500 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-model-02.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. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Forwarding Element Functional Model Author(s) : L. Yang Filename : draft-ietf-forces-model-02.txt Pages : 101 Date : 2004-2-17 This document defines the forwarding element (FE) model used in the Forwarding and Control Plane Separation (ForCES) protocol. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements draft [1]. A list of the basic logical functional blocks (LFBs) is also defined in the LFB class library to aid the effort in defining individual LFBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.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-model-02.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-model-02.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: <2004-2-17103147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17103147.I-D@ietf.org> --OtherAccess-- --NextPart-- 2004 Message-Id: Date: Tue, 17 Feb 2004 08:49:27 -0800 From: "Yang, Lily L" Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all -- The FE model design team just published v02 of the FE model document. The entire document has been edited throughout, but most notably some major progress has been reflected in this revision: 1) 3.2.4 "metadata" section is completely rewritten, with the metadata model that was published to this list by Zsolt a few weeks ago. We believe most comments we've received so far are addressed in this revision. 2) Section 4 "model and schema for LFB classes" is rewritten, with formal XML schema specified at the end of the section. 3) Section 5 "FE Attributes and Capabilities" now is completed with also formal XML schema specification, that was also published to the list a few weeks ago by Joel. 4) The old section 6 in v01 was a place holder for LFB topology and now gone because the content of LFB topology is merged into "FE attributes and Capabilities" in Section 5. The comments we received are also incorporated into this new revision. 5) Section 6 "LFB Class Library" (old section 7 in v01) is also revised significantly with now 18 LFB classes that include the most commonly found functions for IP processing, forwarding and QoS. 6) Section 7 "satisfying the requirements" (old section 8 in v01) is also revised considerably. With this revision, the major pieces that make up the FE model are now in place, with the exception of a few minor features here and there (e.g., class inheritance is not fully flushed out in the LFB schema). We hope this revision would provide timely input into the protocol development. In the meantime, we hope the WG and especially the protocol designers would take time to review and provide feedback on the FE model, so that we can refine it to the satisfaction of the WG in the next few months. Thank you all, Lily -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 17, 2004 7:32 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: I-D ACTION:draft-ietf-forces-model-02.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 : ForCES Forwarding Element Functional Model Author(s) : L. Yang Filename : draft-ietf-forces-model-02.txt Pages : 101 Date : 2004-2-17 This document defines the forwarding element (FE) model used in the Forwarding and Control Plane Separation (ForCES) protocol. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements draft [1]. A list of the basic logical functional blocks (LFBs) is also defined in the LFB class library to aid the effort in defining individual LFBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.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-model-02.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-model-02.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. 2004 Message-Id: Date: Mon, 9 Feb 2004 13:31:58 -0500 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Document Action: 'Forwarding and Control Element Separation (ForCES) Framework' to Informational RFC Comments: cc: Internet Architecture Board , RFC Editor The IESG has approved the following document: - 'Forwarding and Control Element Separation (ForCES) Framework ' as an Informational RFC This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. 2004 Message-Id: Date: Fri, 6 Feb 2004 10:07:08 +0900 From: avri@acm.org Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I don't think I quite agree. Yes FE-FE _protocols_ are out of scope. but LFB - LFB even when across FE should not be out of scope for the model. How that info get conveyed across the FE boundary is out of scope, but the info should not be. So I guess I am saying that I see (3) as more then just nice. a. On 6 feb 2004, at 02.41, Yang, Lily L wrote: > Jamal -- I don't quite understand your last statement below. Don't you > agree: > 1) FE-FE is indeed out of scope for now. > 2) In prinicple, the metadata model that Zsolt posted is still > necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) > metadata modeling. > 3) It is extra nice (bonus) if this same metadata model can work > across both intra-FE and inter-FE domain. > > It is absolutely important for the WG to agree on 1) and 2) above. 3) > is optional but nice to have, so lets not be too concerned about it > for the time being. > > Lily > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Thursday, February 05, 2004 8:56 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Metadata model for the ForCES model > > > The problem (challenge actually) is this stuff exists already. > Looking the other way may not be the best option. > I agree with Zsolt's statements below. > If we want to say its outside the scope, then the text on metdata > that Zsolt posted is overkill already and may need a lot of chopping. > > cheers, > jamal > > On Wed, 2004-02-04 at 12:31, Alex Audu wrote: >> I am assuming this meta-data thing is all in context of having the CE >> successfully >> configure the FEs. Unless this requires FE-FE communication, I >> don't see any >> reasons for extending this to include FE-FE. >> >> Regards, >> Alex. >> >> >> Zsolt Haraszti wrote: >> >>> A couple of comments: >>> >>> 1. The fact is that most real distributed (multiblade) routers >>> forward metadata from one blade (e.g., ingresss) to another >>> (e.g., egress). This simply allows optimal distribution of >>> processing functions across the involved FEs. >>> Not only that they forward metadata in addition to the IP packet >>> being sent, but it may also be that the packet is not a >>> complete/valid IP packet. Since this is all within the node, >>> it's all legitimate. >>> >>> 2. Just because it is not an IP packet or not only an IP packet, >>> it does not mean that ForCES must include it in its scope. >>> If it is not in the scope, so be it. Then it will be left >>> for the vendors, or to some other standards bodies to deal >>> with it. (FYI, the NPF is addressing the inter-FE metadata >>> encapsulation via a messaging LFB and messaging protocol). >>> BTW, I think the ForCES work is still very useful, even if >>> the inter-FE messaging is not in its scope. >>> >>> 3. Even if the inter-FE messaging could be put into the ForCES >>> scope, we should still ignore it for the time being, and >>> focus on the model and the CE-FE communication. >>> >>> /zsolt >>> >>> Joel M. Halpern wrote: >>>> There probably is an issue of hop count. Personally, I consider >>>> such >>>> double decrementing a very good idea, as it avoids accidental >>>> internal >>>> loops. >>>> >>>> Other than that, the IP addresses are just the interface IP >>>> addresses of >>>> the NE. If the links between the FEs are multi-access, they will >>>> need IP >>>> addresses. They will need them even if that network is otherwise >>>> concealed, and even if the protocol were not IP. >>>> >>>> One can craft all sorts of reasons why it might be nice to treat >>>> the Fi >>>> links differently. And later, we might choose to do so. But the >>>> topology >>>> and scope documents clearly state that we are not defining a >>>> protocol for >>>> that. And we can meet a reasonable definition of a "single system >>>> image" >>>> without defining or using a special protocol on those links. >>>> Given that the system works when we treat those links as carrying >>>> IP over >>>> BACK (ie any technology used for the interconnect which supports IP >>>> packets) it seems that we keep our work bounded and within defined >>>> scope if >>>> for now we just use that. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: >>>> >>>>> Well, if IP is used between FEs, without any metadata in the >>>>> exchange, >>>>> then wouldn't it involve forwarding as it it were a hop? And >>>>> while it >>>>> is true that the receiving FE could treat the packet specially and >>>>> not >>>>> modify the packet based on the extra hop, this would involve >>>>> implicit >>>>> 'metadata' that this wasn't being forwarded from outside the NE >>>>> and not >>>>> as if between NEs. >>>>> >>>>> Also, wouldn't there be a concern with the assignment of IP >>>>> addresses >>>>> to each of the FEs. Or would this be done based on some internal >>>>> private IP address space. >>>>> >>>>> Maybe I don't really understand what you mean when you say an FE >>>>> passes >>>>> a packet to another FE as if it were being passed to another NE. >>>>> >>>>> a. >>>>> >>>>> On 2004-02-04, at 10.22, Joel M. Halpern wrote: >>>>> >>>>>> I do not believe that would violate single system appearence at >>>>>> all. >>>>>> Appearing as a single system is a matter of management protocol >>>>>> interactions and routing protocol advertisements. It has nothing >>>>>> to do >>>>>> with the packets flowing between FEs. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>>>>> >>>>>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>>>>>> >>>>>>>> In general, given that Fi is outside of scope, I think of all >>>>>>>> traffic >>>>>>>> to >>>>>>>> another FE as if it were to another NE. >>>>>>> >>>>>>> >>>>>>> Wouldn't that violate the rule that an NE, no matter how many >>>>>>> parts it >>>>>>> is composed of, should appear to be a single entity. If we >>>>>>> assume >>>>>>> that >>>>>>> FE-FE messaging is normal IP as if it were NE-NE then we may have >>>>>>> problems meeting that requirement. >>>>>>> >>>>>>> I agree the current charter prohibits making FE-FE protocols a >>>>>>> work >>>>>>> item, but I don't think that eliminates the need for >>>>>>> implementations >>>>>>> to >>>>>>> have a solution other then the passing of straight IP packets. >>>>>>> Including a metadata model that covers this seems like a good >>>>>>> idea. >>>>>>> Personally I am glad someone is working on it. I know I am more >>>>>>> concerned with the WG getting the model right then worrying about >>>>>>> specific protocol implementations. >>>>>>> >>>>>>> a. >>>> >>>> >>>> > 2004 Message-Id: Date: Thu, 5 Feb 2004 17:37:45 -0800 From: "Yang, Lily L" Subject: Re: Metadata model for the ForCES model Comments: To: avri@acm.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok. Let me try to ask this differently then: 1) Is there anything in this metadata model proposal that would not work = for LFB-LFB crossing FE boundary? 2) Is there anything in this model that is ONLY useful for LFB-LFB = crossing FE boundary?=20 My own answeres to both these questions are No. Bottom line: I don't see how this distinction (crossing FE or not) = affect the substance of the metadata model here.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of avri@acm.org Sent: Thursday, February 05, 2004 5:07 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Metadata model for the ForCES model I don't think I quite agree. Yes FE-FE _protocols_ are out of scope. but LFB - LFB even when across FE should not be out of scope for the model. How that info get conveyed across the FE boundary is out of scope, but the info should not be. So I guess I am saying that I see (3) as more then just nice. a. On 6 feb 2004, at 02.41, Yang, Lily L wrote: > Jamal -- I don't quite understand your last statement below. Don't you > agree: > 1) FE-FE is indeed out of scope for now. > 2) In prinicple, the metadata model that Zsolt posted is still > necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) > metadata modeling. > 3) It is extra nice (bonus) if this same metadata model can work > across both intra-FE and inter-FE domain. > > It is absolutely important for the WG to agree on 1) and 2) above. 3) > is optional but nice to have, so lets not be too concerned about it > for the time being. > > Lily > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Thursday, February 05, 2004 8:56 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Metadata model for the ForCES model > > > The problem (challenge actually) is this stuff exists already. > Looking the other way may not be the best option. > I agree with Zsolt's statements below. > If we want to say its outside the scope, then the text on metdata > that Zsolt posted is overkill already and may need a lot of chopping. > > cheers, > jamal > > On Wed, 2004-02-04 at 12:31, Alex Audu wrote: >> I am assuming this meta-data thing is all in context of having the CE >> successfully >> configure the FEs. Unless this requires FE-FE communication, I >> don't see any >> reasons for extending this to include FE-FE. >> >> Regards, >> Alex. >> >> >> Zsolt Haraszti wrote: >> >>> A couple of comments: >>> >>> 1. The fact is that most real distributed (multiblade) routers >>> forward metadata from one blade (e.g., ingresss) to another >>> (e.g., egress). This simply allows optimal distribution of >>> processing functions across the involved FEs. >>> Not only that they forward metadata in addition to the IP packet >>> being sent, but it may also be that the packet is not a >>> complete/valid IP packet. Since this is all within the node, >>> it's all legitimate. >>> >>> 2. Just because it is not an IP packet or not only an IP packet, >>> it does not mean that ForCES must include it in its scope. >>> If it is not in the scope, so be it. Then it will be left >>> for the vendors, or to some other standards bodies to deal >>> with it. (FYI, the NPF is addressing the inter-FE metadata >>> encapsulation via a messaging LFB and messaging protocol). >>> BTW, I think the ForCES work is still very useful, even if >>> the inter-FE messaging is not in its scope. >>> >>> 3. Even if the inter-FE messaging could be put into the ForCES >>> scope, we should still ignore it for the time being, and >>> focus on the model and the CE-FE communication. >>> >>> /zsolt >>> >>> Joel M. Halpern wrote: >>>> There probably is an issue of hop count. Personally, I consider >>>> such >>>> double decrementing a very good idea, as it avoids accidental >>>> internal >>>> loops. >>>> >>>> Other than that, the IP addresses are just the interface IP >>>> addresses of >>>> the NE. If the links between the FEs are multi-access, they will >>>> need IP >>>> addresses. They will need them even if that network is otherwise >>>> concealed, and even if the protocol were not IP. >>>> >>>> One can craft all sorts of reasons why it might be nice to treat >>>> the Fi >>>> links differently. And later, we might choose to do so. But the >>>> topology >>>> and scope documents clearly state that we are not defining a >>>> protocol for >>>> that. And we can meet a reasonable definition of a "single system >>>> image" >>>> without defining or using a special protocol on those links. >>>> Given that the system works when we treat those links as carrying >>>> IP over >>>> BACK (ie any technology used for the interconnect which supports IP >>>> packets) it seems that we keep our work bounded and within defined >>>> scope if >>>> for now we just use that. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: >>>> >>>>> Well, if IP is used between FEs, without any metadata in the >>>>> exchange, >>>>> then wouldn't it involve forwarding as it it were a hop? And >>>>> while it >>>>> is true that the receiving FE could treat the packet specially and >>>>> not >>>>> modify the packet based on the extra hop, this would involve >>>>> implicit >>>>> 'metadata' that this wasn't being forwarded from outside the NE >>>>> and not >>>>> as if between NEs. >>>>> >>>>> Also, wouldn't there be a concern with the assignment of IP >>>>> addresses >>>>> to each of the FEs. Or would this be done based on some internal >>>>> private IP address space. >>>>> >>>>> Maybe I don't really understand what you mean when you say an FE >>>>> passes >>>>> a packet to another FE as if it were being passed to another NE. >>>>> >>>>> a. >>>>> >>>>> On 2004-02-04, at 10.22, Joel M. Halpern wrote: >>>>> >>>>>> I do not believe that would violate single system appearence at >>>>>> all. >>>>>> Appearing as a single system is a matter of management protocol >>>>>> interactions and routing protocol advertisements. It has nothing >>>>>> to do >>>>>> with the packets flowing between FEs. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>>>>> >>>>>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>>>>>> >>>>>>>> In general, given that Fi is outside of scope, I think of all >>>>>>>> traffic >>>>>>>> to >>>>>>>> another FE as if it were to another NE. >>>>>>> >>>>>>> >>>>>>> Wouldn't that violate the rule that an NE, no matter how many >>>>>>> parts it >>>>>>> is composed of, should appear to be a single entity. If we >>>>>>> assume >>>>>>> that >>>>>>> FE-FE messaging is normal IP as if it were NE-NE then we may = have >>>>>>> problems meeting that requirement. >>>>>>> >>>>>>> I agree the current charter prohibits making FE-FE protocols a >>>>>>> work >>>>>>> item, but I don't think that eliminates the need for >>>>>>> implementations >>>>>>> to >>>>>>> have a solution other then the passing of straight IP packets. >>>>>>> Including a metadata model that covers this seems like a good >>>>>>> idea. >>>>>>> Personally I am glad someone is working on it. I know I am more >>>>>>> concerned with the WG getting the model right then worrying = about >>>>>>> specific protocol implementations. >>>>>>> >>>>>>> a. >>>> >>>> >>>> > 2004 Message-Id: Date: Thu, 5 Feb 2004 12:50:03 -0500 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata model for the ForCES model Comments: To: "Yang, Lily L" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2004-02-05 at 12:41, Yang, Lily L wrote: > Jamal -- I don't quite understand your last statement below. Don't you agree: > 1) FE-FE is indeed out of scope for now. > 2) In prinicple, the metadata model that Zsolt posted is still necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) metadata modeling. > 3) It is extra nice (bonus) if this same metadata model can work across both intra-FE and inter-FE domain. > > It is absolutely important for the WG to agree on 1) and 2) above. 3) is optional but nice to have, so lets not be too concerned about it for the time being. > I dont see why modelling 3) should be any different. The transporting of such metadata is definetely out of scope. cheers, jamal 2004 Message-Id: Date: Thu, 5 Feb 2004 12:15:02 -0800 From: "Putzolu, David" Subject: Re: IESG on draft-ietf-forces-framework Comments: To: Alex Zinin MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Congratulations all on a job well done, and thank you Alex & a host of others (including IESG members, routing directorate, security advisors, and more) for all your help & patience! Cheers, David=20 > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin > Sent: Thursday, February 05, 2004 12:03 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] IESG on draft-ietf-forces-framework >=20 > Folks- >=20 > FYI, the IESG approved the draft-ietf-forces-framework=20 > document this morning. A formal announcement to appear shortly. >=20 > Thanks all for good work! >=20 > -- > Alex > http://www.psg.com/~zinin/ >=20 2004 Message-Id: Date: Thu, 5 Feb 2004 12:03:23 -0800 From: Alex Zinin Subject: IESG on draft-ietf-forces-framework MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- FYI, the IESG approved the draft-ietf-forces-framework document this morning. A formal announcement to appear shortly. Thanks all for good work! -- Alex http://www.psg.com/~zinin/ 2004 Message-Id: Date: Thu, 5 Feb 2004 12:03:13 -0500 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: ForCES Design Meeting Info: Sunday, February 29 @ IETF Hotel in Korea Comments: To: "Putzolu, David" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain David, For this to be effective good representation from all protocol drafts in atome format would be needed. So far 75% of the netlink2 draft authors (we have a new oauthor) have confirmed they wont be going. I dont think the concal alone would cut it. So i suggest we defer this until after Seoul. It would be a good idea to start discussion via email (which should initially be restricted to protocol authors only and opened up after to other people to reduce noise). cheers, jamal On Wed, 2004-02-04 at 21:04, Putzolu, David wrote: > All, > > A ForCES design meeting with open attendance > is tentatively scheduled with the following > date/time/location: > > Time: Sunday, February 29, 10:00am Local time > Location: Lotte Hotel-Seoul, Korea > > The goal of this meeting will be to determine if a > merged protocol proposal is possible, and if so, to > begin moving forward on creating such a proposal. > Note that it would be desirable if interested > parties work ahead of time to come prepared to the > meeting with proposals. > > A phone bridge will be provided for remote > participants to call in to. > > Please email me if you will be attending. > If you cannot attend at this time but could > attend a later time on Sunday, please email me > with that information. > > Thanks, > David 2004 Message-Id: Date: Thu, 5 Feb 2004 11:56:14 -0500 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata model for the ForCES model Comments: To: alex.audu@alcatel.com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain The problem (challenge actually) is this stuff exists already. Looking the other way may not be the best option. I agree with Zsolt's statements below. If we want to say its outside the scope, then the text on metdata that Zsolt posted is overkill already and may need a lot of chopping. cheers, jamal On Wed, 2004-02-04 at 12:31, Alex Audu wrote: > I am assuming this meta-data thing is all in context of having the CE > successfully > configure the FEs. Unless this requires FE-FE communication, I don't see any > reasons for extending this to include FE-FE. > > Regards, > Alex. > > > Zsolt Haraszti wrote: > > > A couple of comments: > > > > 1. The fact is that most real distributed (multiblade) routers > > forward metadata from one blade (e.g., ingresss) to another > > (e.g., egress). This simply allows optimal distribution of > > processing functions across the involved FEs. > > Not only that they forward metadata in addition to the IP packet > > being sent, but it may also be that the packet is not a > > complete/valid IP packet. Since this is all within the node, > > it's all legitimate. > > > > 2. Just because it is not an IP packet or not only an IP packet, > > it does not mean that ForCES must include it in its scope. > > If it is not in the scope, so be it. Then it will be left > > for the vendors, or to some other standards bodies to deal > > with it. (FYI, the NPF is addressing the inter-FE metadata > > encapsulation via a messaging LFB and messaging protocol). > > BTW, I think the ForCES work is still very useful, even if > > the inter-FE messaging is not in its scope. > > > > 3. Even if the inter-FE messaging could be put into the ForCES > > scope, we should still ignore it for the time being, and > > focus on the model and the CE-FE communication. > > > > /zsolt > > > > Joel M. Halpern wrote: > > > There probably is an issue of hop count. Personally, I consider such > > > double decrementing a very good idea, as it avoids accidental internal > > > loops. > > > > > > Other than that, the IP addresses are just the interface IP addresses of > > > the NE. If the links between the FEs are multi-access, they will need IP > > > addresses. They will need them even if that network is otherwise > > > concealed, and even if the protocol were not IP. > > > > > > One can craft all sorts of reasons why it might be nice to treat the Fi > > > links differently. And later, we might choose to do so. But the topology > > > and scope documents clearly state that we are not defining a protocol for > > > that. And we can meet a reasonable definition of a "single system image" > > > without defining or using a special protocol on those links. > > > Given that the system works when we treat those links as carrying IP over > > > BACK (ie any technology used for the interconnect which supports IP > > > packets) it seems that we keep our work bounded and within defined scope if > > > for now we just use that. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > > > > > >> Well, if IP is used between FEs, without any metadata in the exchange, > > >> then wouldn't it involve forwarding as it it were a hop? And while it > > >> is true that the receiving FE could treat the packet specially and not > > >> modify the packet based on the extra hop, this would involve implicit > > >> 'metadata' that this wasn't being forwarded from outside the NE and not > > >> as if between NEs. > > >> > > >> Also, wouldn't there be a concern with the assignment of IP addresses > > >> to each of the FEs. Or would this be done based on some internal > > >> private IP address space. > > >> > > >> Maybe I don't really understand what you mean when you say an FE passes > > >> a packet to another FE as if it were being passed to another NE. > > >> > > >> a. > > >> > > >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: > > >> > > >>> I do not believe that would violate single system appearence at all. > > >>> Appearing as a single system is a matter of management protocol > > >>> interactions and routing protocol advertisements. It has nothing to do > > >>> with the packets flowing between FEs. > > >>> > > >>> Yours, > > >>> Joel M. Halpern > > >>> > > >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: > > >>> > > >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: > > >>>> > > >>>>> In general, given that Fi is outside of scope, I think of all traffic > > >>>>> to > > >>>>> another FE as if it were to another NE. > > >>>> > > >>>> > > >>>> Wouldn't that violate the rule that an NE, no matter how many parts it > > >>>> is composed of, should appear to be a single entity. If we assume > > >>>> that > > >>>> FE-FE messaging is normal IP as if it were NE-NE then we may have > > >>>> problems meeting that requirement. > > >>>> > > >>>> I agree the current charter prohibits making FE-FE protocols a work > > >>>> item, but I don't think that eliminates the need for implementations > > >>>> to > > >>>> have a solution other then the passing of straight IP packets. > > >>>> Including a metadata model that covers this seems like a good idea. > > >>>> Personally I am glad someone is working on it. I know I am more > > >>>> concerned with the WG getting the model right then worrying about > > >>>> specific protocol implementations. > > >>>> > > >>>> a. > > > > > > > > > 2004 Message-Id: Date: Thu, 5 Feb 2004 11:46:27 -0500 From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata model for the ForCES model Comments: To: Zsolt Haraszti Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Tue, 2004-02-03 at 16:13, Zsolt Haraszti wrote: > On Sun, 2004-02-01 at 10:14, Jamal Hadi Salim wrote: [..] > Between FEs's, however, the model does put some requirements on the > implementation. At the minimum, it implies that a certain set of > information (i.e., the set of metadata that is present at the > exit point on FE1 and needed for further processing on FE2) must be > passed _in some way_ between the two FEs. How it is passed is left > to the vendors at this point. One can speculate that many vendors > would benefit from something less proprietary, so I expect that > ForCES will eventually start working on that area. When the work > starts, it will have to take this metadata model into consideration. Just to clarify what i was refering to is communication over something like XAUI or CSIX inter-connected LFBs/FEs. It may get funky with path MTUs with ethernet for example. I am also not about to change chip vendors view of the world on already deployed products. However i see no reason not to have the metadata carried along with the packet. I think it will be a good idea you add text to at least emphasize things in regards to LFBs across FEs. I agree on it being beyond ForCES as is now. > only a portion of this text will go into the revised draft. Much of > the motivation/justification text, including the above, will probably > not make it. When you make changes please post a diff -du of the two files. It is easier to read. I think the idea of mentioning "registers" should be left out of the text. > > + section 4 The Proposed Metadata Model > > > > - I think a TLV with flags would be appropriately model metadata. > > [tag = type; split the type bits into some 4 bits for flags] > Your thinking may be to protocol driven. Again, this model--so far-- > is mainly to describe a reference model w.r.t. how data passing should > be envisioned when defining LFBs, their attributes, and the CE-FE > protocol communication. It is not about how to actually pass > metadata among LFBs. For the above (reduced) scope, it has some > benefits to regard most metadata values as 32 bit integers. You have defined a Tag (that T) which takes a Value (that V). I believe you could model better by not restricting the L to 4. > BTW, what is the intended usage of the flags? I was thinking you could carry the permissions for example such as READ, WRITE etc; maybe they dont fit. > > > > + section 5 Metadata Production and Consumption > > "There may be multiple consumers for the same metadata" > > is repeated twice. > > - wasnt clear on the "conditional" aspect of metadata; could you provide > > a real example? > I do not have very strong examples to support this. What I had > in mind was cases when the need for a metadata depends on the > value of another metadata. For example, one metadata is a > RESULTKEY, and another is an ERRORCODE. RESULTKEY is normally > used to encode the result of an operation (e.g., a search in > a table), and a special value (0) encodes the lack of result. > When RESULTKEY=0, then ERRORCODE tells more about the reason > of the miss. When RESULTKEY!=0, then ERRORCODE is meaningless, > so it can be omitted. I know that this can be done in other ways > (embedding the error codes into the RESULTKEY value space; > or making ERRORCODE mandatory, but ignore it in downstream > LFBs if RESULTKEY!=0, etc.) I see where you are going with it - it may be overkill. To me this further strengthens the need to model based on TLVs. Clearly ERRORCODE. and RESULTKEY are related; you are already refering to embedding them together...... > Once we go through the exercise of creating a library of fully > defined LFBs and putting together useful configurations we may > conclude that there is no need for this feature. Then we can pull > this out. Until then, I left it in a space-holder. But I can > be convinced... The conditionals are attributes of LFB topology; you may have taken the approach that the topology definition needs metadata to route the packet amongst LFBs (which is an implementation detail). I think you should leave it in for now. > > > > + section 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata > > Production > > > > Isnt the tag selector itself metadata? I think starting this section > > you may be treading into implementation specifics. > I am disconnected here. Consider an Re-director LFB that can be > instantiated to split traffic into multiple streams based on some > input metadata. For example, one instance splits based on a classifier > key (CLASSID), another splits based on COLOR, a third based on > protocolo type (PROTO). This will be realized by an LFB class that > will have the following features (simplistic approach): > 1) Variable number of outputs > 2) An attribute that tells the LFB which metadata tag to look for > 3) A table of entries, where each entry will contain a metadata > value (as a condition), and a port reference (where to send > the packet). > So the selector is an attribute of the LFB, read (or possibly written) > by the CE via the ForCES protocol. Making it an attribute is fine. I was more looking at the view that the producer of the metadatum may also define the tag selector and permissions as metadata which is consumed downstream. > The metadata values of the > table entries should be generic enough to accommodate (almost) > arbitrary metadata. I see a benefit to make such a field in the > table entry a 32-bit integer field (which would serve 95% of > the expected metadata types based on our pre-study); that is what > motivates to have a generic data type for most metadata. Ok, based on your statement above, i see why i was having problems with restricting it to 32-bit. I would define metadata as "execution markers"; the only reason you need metadata is so that you dont repeat work the packet has already been put through. Using metadata for table lookups furher downstream is only a subset of that domain. To illustrate: (The linux kernel does this - apologies for going into imp. its the best example i could think of that you could validate) You could design it such that LFB execution completion could be deffered when preempted by higher prio work. In this case you may wanna later reenter the same LFB but skip some code. This is useful in NPs as well. To achieve this you need to store in metadata not just code pointers but data processed so far. > > +section 9 Metadata Usage Categories > > > - "Another way of setting up binding relations is when a > > naturally occurring unique identifier of the consumer's object" > > What is the event that would cause this? Is it a packet arrival or > > a CE reading something off the FE? > Let me illustrate what I meant here with an example: > Lets say the consumer LFB has a table of things. You may insert a > new entry in the table. The operation returns with a table entry > index, which can be used in subsequent incremental table > management. In the same time, the index can also be used as a > way to refer to the given entry from another LFB. E.g, when an > upstream LFB wants to refer to one of the table entries, it can > send the index in a well-defined metadata. That index is what I > consider "naturally occuring," meaning that it exists anyway > and it can also be used as a binding metadata. So to answer the > original question: the event is a configuration event on the LFB > by the CE. > Reading all the above (and ignoring usage of metadata for a moment) it seems to me you are saying theres two types of metadata from a initial production pespective. Theres metadata that maybe we should call "static" that gets produced by the CE as an LFB attribute. Theres also dynamic metadata that gets created or destroyed by other events such as packet arrivals on the producer LFB or timers expiring (eg a cache table entry creation/deletion). > > - "The value of the enumerated metadata may or may not be conveyed > > via the ForCES protocol between the CE and FE." > > > > Didnt grasp that. How are LFBs on an FE supposed to cooperate on values > > of metadata if they are not synced in this case? > Consider a Rate Meter LFB that emits COLOR as metadata. Consider > a downstream Rate Meter LFB that uses the COLOR metadata to do further > rate metering. To neither of the LFB instances would we ever > communicate COLOR as part of the CE-FE communication. It is all > built in in the specification of the LFB class and the specification > of the COLOR metadata. So this is an example when the enumerated > metadata is not conveyed between the CE and FE. > Right - but the attribute is still part of the LFB setup (via CE-FE protocol). i.e from a LFB topology level theres still synchronization that is happening. cheers, jamal 2004 Message-Id: Date: Thu, 5 Feb 2004 09:41:11 -0800 From: "Yang, Lily L" Subject: Re: Metadata model for the ForCES model Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jamal -- I don't quite understand your last statement below. Don't you = agree: 1) FE-FE is indeed out of scope for now. 2) In prinicple, the metadata model that Zsolt posted is still necessary = (i.e., not overkill) even just for intra-FE (LFB to LFB) metadata = modeling. 3) It is extra nice (bonus) if this same metadata model can work across = both intra-FE and inter-FE domain.=20 It is absolutely important for the WG to agree on 1) and 2) above. 3) is = optional but nice to have, so lets not be too concerned about it for the = time being. Lily -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim Sent: Thursday, February 05, 2004 8:56 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Metadata model for the ForCES model The problem (challenge actually) is this stuff exists already. Looking the other way may not be the best option. I agree with Zsolt's statements below. If we want to say its outside the scope, then the text on metdata that Zsolt posted is overkill already and may need a lot of chopping. cheers, jamal On Wed, 2004-02-04 at 12:31, Alex Audu wrote: > I am assuming this meta-data thing is all in context of having the CE > successfully > configure the FEs. Unless this requires FE-FE communication, I don't = see any > reasons for extending this to include FE-FE. > > Regards, > Alex. > > > Zsolt Haraszti wrote: > > > A couple of comments: > > > > 1. The fact is that most real distributed (multiblade) routers > > forward metadata from one blade (e.g., ingresss) to another > > (e.g., egress). This simply allows optimal distribution of > > processing functions across the involved FEs. > > Not only that they forward metadata in addition to the IP packet > > being sent, but it may also be that the packet is not a > > complete/valid IP packet. Since this is all within the node, > > it's all legitimate. > > > > 2. Just because it is not an IP packet or not only an IP packet, > > it does not mean that ForCES must include it in its scope. > > If it is not in the scope, so be it. Then it will be left > > for the vendors, or to some other standards bodies to deal > > with it. (FYI, the NPF is addressing the inter-FE metadata > > encapsulation via a messaging LFB and messaging protocol). > > BTW, I think the ForCES work is still very useful, even if > > the inter-FE messaging is not in its scope. > > > > 3. Even if the inter-FE messaging could be put into the ForCES > > scope, we should still ignore it for the time being, and > > focus on the model and the CE-FE communication. > > > > /zsolt > > > > Joel M. Halpern wrote: > > > There probably is an issue of hop count. Personally, I consider = such > > > double decrementing a very good idea, as it avoids accidental = internal > > > loops. > > > > > > Other than that, the IP addresses are just the interface IP = addresses of > > > the NE. If the links between the FEs are multi-access, they will = need IP > > > addresses. They will need them even if that network is otherwise > > > concealed, and even if the protocol were not IP. > > > > > > One can craft all sorts of reasons why it might be nice to treat = the Fi > > > links differently. And later, we might choose to do so. But the = topology > > > and scope documents clearly state that we are not defining a = protocol for > > > that. And we can meet a reasonable definition of a "single system = image" > > > without defining or using a special protocol on those links. > > > Given that the system works when we treat those links as carrying = IP over > > > BACK (ie any technology used for the interconnect which supports = IP > > > packets) it seems that we keep our work bounded and within defined = scope if > > > for now we just use that. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > > > > > >> Well, if IP is used between FEs, without any metadata in the = exchange, > > >> then wouldn't it involve forwarding as it it were a hop? And = while it > > >> is true that the receiving FE could treat the packet specially = and not > > >> modify the packet based on the extra hop, this would involve = implicit > > >> 'metadata' that this wasn't being forwarded from outside the NE = and not > > >> as if between NEs. > > >> > > >> Also, wouldn't there be a concern with the assignment of IP = addresses > > >> to each of the FEs. Or would this be done based on some internal > > >> private IP address space. > > >> > > >> Maybe I don't really understand what you mean when you say an FE = passes > > >> a packet to another FE as if it were being passed to another NE. > > >> > > >> a. > > >> > > >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: > > >> > > >>> I do not believe that would violate single system appearence at = all. > > >>> Appearing as a single system is a matter of management protocol > > >>> interactions and routing protocol advertisements. It has = nothing to do > > >>> with the packets flowing between FEs. > > >>> > > >>> Yours, > > >>> Joel M. Halpern > > >>> > > >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: > > >>> > > >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: > > >>>> > > >>>>> In general, given that Fi is outside of scope, I think of all = traffic > > >>>>> to > > >>>>> another FE as if it were to another NE. > > >>>> > > >>>> > > >>>> Wouldn't that violate the rule that an NE, no matter how many = parts it > > >>>> is composed of, should appear to be a single entity. If we = assume > > >>>> that > > >>>> FE-FE messaging is normal IP as if it were NE-NE then we may = have > > >>>> problems meeting that requirement. > > >>>> > > >>>> I agree the current charter prohibits making FE-FE protocols a = work > > >>>> item, but I don't think that eliminates the need for = implementations > > >>>> to > > >>>> have a solution other then the passing of straight IP packets. > > >>>> Including a metadata model that covers this seems like a good = idea. > > >>>> Personally I am glad someone is working on it. I know I am = more > > >>>> concerned with the WG getting the model right then worrying = about > > >>>> specific protocol implementations. > > >>>> > > >>>> a. > > > > > > > > > 2004 Message-Id: Date: Wed, 4 Feb 2004 18:04:57 -0800 From: "Putzolu, David" Subject: ForCES Design Meeting Info: Sunday, February 29 @ IETF Hotel in Korea MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, A ForCES design meeting with open attendance=20 is tentatively scheduled with the following=20 date/time/location: Time: Sunday, February 29, 10:00am Local time Location: Lotte Hotel-Seoul, Korea The goal of this meeting will be to determine if a merged protocol proposal is possible, and if so, to begin moving forward on creating such a proposal. Note that it would be desirable if interested parties work ahead of time to come prepared to the meeting with proposals. A phone bridge will be provided for remote=20 participants to call in to. Please email me if you will be attending. If you cannot attend at this time but could attend a later time on Sunday, please email me=20 with that information. Thanks, David 2004 Message-Id: Date: Wed, 4 Feb 2004 11:31:09 -0600 From: Alex Audu Subject: Re: Metadata model for the ForCES model Comments: To: zsolt.haraszti@ericsson.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am assuming this meta-data thing is all in context of having the CE successfully configure the FEs. Unless this requires FE-FE communication, I don't see any reasons for extending this to include FE-FE. Regards, Alex. Zsolt Haraszti wrote: > A couple of comments: > > 1. The fact is that most real distributed (multiblade) routers > forward metadata from one blade (e.g., ingresss) to another > (e.g., egress). This simply allows optimal distribution of > processing functions across the involved FEs. > Not only that they forward metadata in addition to the IP packet > being sent, but it may also be that the packet is not a > complete/valid IP packet. Since this is all within the node, > it's all legitimate. > > 2. Just because it is not an IP packet or not only an IP packet, > it does not mean that ForCES must include it in its scope. > If it is not in the scope, so be it. Then it will be left > for the vendors, or to some other standards bodies to deal > with it. (FYI, the NPF is addressing the inter-FE metadata > encapsulation via a messaging LFB and messaging protocol). > BTW, I think the ForCES work is still very useful, even if > the inter-FE messaging is not in its scope. > > 3. Even if the inter-FE messaging could be put into the ForCES > scope, we should still ignore it for the time being, and > focus on the model and the CE-FE communication. > > /zsolt > > Joel M. Halpern wrote: > > There probably is an issue of hop count. Personally, I consider such > > double decrementing a very good idea, as it avoids accidental internal > > loops. > > > > Other than that, the IP addresses are just the interface IP addresses of > > the NE. If the links between the FEs are multi-access, they will need IP > > addresses. They will need them even if that network is otherwise > > concealed, and even if the protocol were not IP. > > > > One can craft all sorts of reasons why it might be nice to treat the Fi > > links differently. And later, we might choose to do so. But the topology > > and scope documents clearly state that we are not defining a protocol for > > that. And we can meet a reasonable definition of a "single system image" > > without defining or using a special protocol on those links. > > Given that the system works when we treat those links as carrying IP over > > BACK (ie any technology used for the interconnect which supports IP > > packets) it seems that we keep our work bounded and within defined scope if > > for now we just use that. > > > > Yours, > > Joel M. Halpern > > > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > > > >> Well, if IP is used between FEs, without any metadata in the exchange, > >> then wouldn't it involve forwarding as it it were a hop? And while it > >> is true that the receiving FE could treat the packet specially and not > >> modify the packet based on the extra hop, this would involve implicit > >> 'metadata' that this wasn't being forwarded from outside the NE and not > >> as if between NEs. > >> > >> Also, wouldn't there be a concern with the assignment of IP addresses > >> to each of the FEs. Or would this be done based on some internal > >> private IP address space. > >> > >> Maybe I don't really understand what you mean when you say an FE passes > >> a packet to another FE as if it were being passed to another NE. > >> > >> a. > >> > >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: > >> > >>> I do not believe that would violate single system appearence at all. > >>> Appearing as a single system is a matter of management protocol > >>> interactions and routing protocol advertisements. It has nothing to do > >>> with the packets flowing between FEs. > >>> > >>> Yours, > >>> Joel M. Halpern > >>> > >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: > >>> > >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: > >>>> > >>>>> In general, given that Fi is outside of scope, I think of all traffic > >>>>> to > >>>>> another FE as if it were to another NE. > >>>> > >>>> > >>>> Wouldn't that violate the rule that an NE, no matter how many parts it > >>>> is composed of, should appear to be a single entity. If we assume > >>>> that > >>>> FE-FE messaging is normal IP as if it were NE-NE then we may have > >>>> problems meeting that requirement. > >>>> > >>>> I agree the current charter prohibits making FE-FE protocols a work > >>>> item, but I don't think that eliminates the need for implementations > >>>> to > >>>> have a solution other then the passing of straight IP packets. > >>>> Including a metadata model that covers this seems like a good idea. > >>>> Personally I am glad someone is working on it. I know I am more > >>>> concerned with the WG getting the model right then worrying about > >>>> specific protocol implementations. > >>>> > >>>> a. > > > > > > 2004 Message-Id: Date: Wed, 4 Feb 2004 11:04:17 +0900 From: avri@acm.org Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Well, if IP is used between FEs, without any metadata in the exchange, then wouldn't it involve forwarding as it it were a hop? And while it is true that the receiving FE could treat the packet specially and not modify the packet based on the extra hop, this would involve implicit 'metadata' that this wasn't being forwarded from outside the NE and not as if between NEs. Also, wouldn't there be a concern with the assignment of IP addresses to each of the FEs. Or would this be done based on some internal private IP address space. Maybe I don't really understand what you mean when you say an FE passes a packet to another FE as if it were being passed to another NE. a. On 2004-02-04, at 10.22, Joel M. Halpern wrote: > I do not believe that would violate single system appearence at all. > Appearing as a single system is a matter of management protocol > interactions and routing protocol advertisements. It has nothing to do > with the packets flowing between FEs. > > Yours, > Joel M. Halpern > > At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >> >>> In general, given that Fi is outside of scope, I think of all traffic >>> to >>> another FE as if it were to another NE. >> >> Wouldn't that violate the rule that an NE, no matter how many parts it >> is composed of, should appear to be a single entity. If we assume >> that >> FE-FE messaging is normal IP as if it were NE-NE then we may have >> problems meeting that requirement. >> >> I agree the current charter prohibits making FE-FE protocols a work >> item, but I don't think that eliminates the need for implementations >> to >> have a solution other then the passing of straight IP packets. >> Including a metadata model that covers this seems like a good idea. >> Personally I am glad someone is working on it. I know I am more >> concerned with the WG getting the model right then worrying about >> specific protocol implementations. >> >> a. > 2004 Message-Id: Date: Wed, 4 Feb 2004 10:13:57 +0900 From: avri@acm.org Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2004-02-04, at 07.25, Joel M. Halpern wrote: > In general, given that Fi is outside of scope, I think of all traffic > to > another FE as if it were to another NE. > Wouldn't that violate the rule that an NE, no matter how many parts it is composed of, should appear to be a single entity. If we assume that FE-FE messaging is normal IP as if it were NE-NE then we may have problems meeting that requirement. I agree the current charter prohibits making FE-FE protocols a work item, but I don't think that eliminates the need for implementations to have a solution other then the passing of straight IP packets. Including a metadata model that covers this seems like a good idea. Personally I am glad someone is working on it. I know I am more concerned with the WG getting the model right then worrying about specific protocol implementations. a. 2004 Message-Id: Date: Wed, 4 Feb 2004 10:00:38 -0800 From: "Putzolu, David" Subject: Interim meeting update (was: FORCES] Protocol Selection Process: Merger Suggestion) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All,=20 After having reviewed possible dates, venues, and logistics,=20 it appears that an interim ForCES meeting in mid-February is=20 not feasible at this time. Having a ForCES meeting on Sunday, February 29, at the=20 IETF 59 hotel site is still under consideration. A final decision will be forthcoming by this Wednesday. Cheers, David P.S. Sorry if this is a duplicate, appeared to bounce to me. > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Friday, January 23, 2004 11:05 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Protocol Selection Process: Merger Suggestion > Importance: High >=20 > All, >=20 > After reviewing the protocol submissions it appears that each of the=20 > proposals has valuable features that merit inclusion in the ForCES=20 > protocol. >=20 > Patrick and I would like to urge the various authors to evaluate=20 > whether a merger of the protocols, selecting the best features of=20 > each, would be possible. >=20 > In order to expedite this process we are considering holding and=20 > interim working group meeting two weeks prior to the next IETF where=20 > interested parties could meet for a day to focus on producing a "best=20 > of all worlds" proposal. >=20 > Please contact Patrick or I if you would be interested in attending=20 > such a meeting. >=20 > Thanks, > David & Patrick > co-chairs, IETF ForCES Working Group >=20 2004 Message-Id: Date: Wed, 4 Feb 2004 09:34:55 -0800 From: "Putzolu, David" Subject: Call for Agenda Items & Drafts, ForCES Meeting @ IETF 59 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Please send me requests for agenda time at the ForCES meeting at IETF 59. If possible, also send over any presentation materials available ahead of time so that the can be made available at the ForCES website. All agenda requests should be made by Monday, February 23. The deadline for submission of new (-00) drafts is Monday, February 9th at 0900 ET. For revisions to=20 existing drafts (-01, -02, etc.), the deadline is Monday, February 16th 0900 ET. Current ForCES agenda information can be found at the ForCES website at: http://www.sstanamera.com/~forces/Ietf59/index.html Thanks, David 2004 Message-Id: Date: Tue, 3 Feb 2004 22:33:46 -0500 From: Zsolt Haraszti Subject: Re: Metadata model for the ForCES model Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A couple of comments: 1. The fact is that most real distributed (multiblade) routers forward metadata from one blade (e.g., ingresss) to another (e.g., egress). This simply allows optimal distribution of processing functions across the involved FEs. Not only that they forward metadata in addition to the IP packet being sent, but it may also be that the packet is not a complete/valid IP packet. Since this is all within the node, it's all legitimate. 2. Just because it is not an IP packet or not only an IP packet, it does not mean that ForCES must include it in its scope. If it is not in the scope, so be it. Then it will be left for the vendors, or to some other standards bodies to deal with it. (FYI, the NPF is addressing the inter-FE metadata encapsulation via a messaging LFB and messaging protocol). BTW, I think the ForCES work is still very useful, even if the inter-FE messaging is not in its scope. 3. Even if the inter-FE messaging could be put into the ForCES scope, we should still ignore it for the time being, and focus on the model and the CE-FE communication. /zsolt Joel M. Halpern wrote: > There probably is an issue of hop count. Personally, I consider such > double decrementing a very good idea, as it avoids accidental internal > loops. > > Other than that, the IP addresses are just the interface IP addresses of > the NE. If the links between the FEs are multi-access, they will need IP > addresses. They will need them even if that network is otherwise > concealed, and even if the protocol were not IP. > > One can craft all sorts of reasons why it might be nice to treat the Fi > links differently. And later, we might choose to do so. But the topology > and scope documents clearly state that we are not defining a protocol for > that. And we can meet a reasonable definition of a "single system image" > without defining or using a special protocol on those links. > Given that the system works when we treat those links as carrying IP over > BACK (ie any technology used for the interconnect which supports IP > packets) it seems that we keep our work bounded and within defined scope if > for now we just use that. > > Yours, > Joel M. Halpern > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > >> Well, if IP is used between FEs, without any metadata in the exchange, >> then wouldn't it involve forwarding as it it were a hop? And while it >> is true that the receiving FE could treat the packet specially and not >> modify the packet based on the extra hop, this would involve implicit >> 'metadata' that this wasn't being forwarded from outside the NE and not >> as if between NEs. >> >> Also, wouldn't there be a concern with the assignment of IP addresses >> to each of the FEs. Or would this be done based on some internal >> private IP address space. >> >> Maybe I don't really understand what you mean when you say an FE passes >> a packet to another FE as if it were being passed to another NE. >> >> a. >> >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: >> >>> I do not believe that would violate single system appearence at all. >>> Appearing as a single system is a matter of management protocol >>> interactions and routing protocol advertisements. It has nothing to do >>> with the packets flowing between FEs. >>> >>> Yours, >>> Joel M. Halpern >>> >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>> >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>>> >>>>> In general, given that Fi is outside of scope, I think of all traffic >>>>> to >>>>> another FE as if it were to another NE. >>>> >>>> >>>> Wouldn't that violate the rule that an NE, no matter how many parts it >>>> is composed of, should appear to be a single entity. If we assume >>>> that >>>> FE-FE messaging is normal IP as if it were NE-NE then we may have >>>> problems meeting that requirement. >>>> >>>> I agree the current charter prohibits making FE-FE protocols a work >>>> item, but I don't think that eliminates the need for implementations >>>> to >>>> have a solution other then the passing of straight IP packets. >>>> Including a metadata model that covers this seems like a good idea. >>>> Personally I am glad someone is working on it. I know I am more >>>> concerned with the WG getting the model right then worrying about >>>> specific protocol implementations. >>>> >>>> a. > > > 2004 Message-Id: Date: Tue, 3 Feb 2004 21:25:59 -0500 From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed There probably is an issue of hop count. Personally, I consider such double decrementing a very good idea, as it avoids accidental internal loops. Other than that, the IP addresses are just the interface IP addresses of the NE. If the links between the FEs are multi-access, they will need IP addresses. They will need them even if that network is otherwise concealed, and even if the protocol were not IP. One can craft all sorts of reasons why it might be nice to treat the Fi links differently. And later, we might choose to do so. But the topology and scope documents clearly state that we are not defining a protocol for that. And we can meet a reasonable definition of a "single system image" without defining or using a special protocol on those links. Given that the system works when we treat those links as carrying IP over BACK (ie any technology used for the interconnect which supports IP packets) it seems that we keep our work bounded and within defined scope if for now we just use that. Yours, Joel M. Halpern At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: >Well, if IP is used between FEs, without any metadata in the exchange, >then wouldn't it involve forwarding as it it were a hop? And while it >is true that the receiving FE could treat the packet specially and not >modify the packet based on the extra hop, this would involve implicit >'metadata' that this wasn't being forwarded from outside the NE and not >as if between NEs. > >Also, wouldn't there be a concern with the assignment of IP addresses >to each of the FEs. Or would this be done based on some internal >private IP address space. > >Maybe I don't really understand what you mean when you say an FE passes >a packet to another FE as if it were being passed to another NE. > >a. > >On 2004-02-04, at 10.22, Joel M. Halpern wrote: > >>I do not believe that would violate single system appearence at all. >>Appearing as a single system is a matter of management protocol >>interactions and routing protocol advertisements. It has nothing to do >>with the packets flowing between FEs. >> >>Yours, >>Joel M. Halpern >> >>At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>>On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>> >>>>In general, given that Fi is outside of scope, I think of all traffic >>>>to >>>>another FE as if it were to another NE. >>> >>>Wouldn't that violate the rule that an NE, no matter how many parts it >>>is composed of, should appear to be a single entity. If we assume >>>that >>>FE-FE messaging is normal IP as if it were NE-NE then we may have >>>problems meeting that requirement. >>> >>>I agree the current charter prohibits making FE-FE protocols a work >>>item, but I don't think that eliminates the need for implementations >>>to >>>have a solution other then the passing of straight IP packets. >>>Including a metadata model that covers this seems like a good idea. >>>Personally I am glad someone is working on it. I know I am more >>>concerned with the WG getting the model right then worrying about >>>specific protocol implementations. >>> >>>a. 2004 Message-Id: Date: Tue, 3 Feb 2004 20:22:05 -0500 From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I do not believe that would violate single system appearence at all. Appearing as a single system is a matter of management protocol interactions and routing protocol advertisements. It has nothing to do with the packets flowing between FEs. Yours, Joel M. Halpern At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >On 2004-02-04, at 07.25, Joel M. Halpern wrote: > >>In general, given that Fi is outside of scope, I think of all traffic >>to >>another FE as if it were to another NE. > >Wouldn't that violate the rule that an NE, no matter how many parts it >is composed of, should appear to be a single entity. If we assume that >FE-FE messaging is normal IP as if it were NE-NE then we may have >problems meeting that requirement. > >I agree the current charter prohibits making FE-FE protocols a work >item, but I don't think that eliminates the need for implementations to >have a solution other then the passing of straight IP packets. >Including a metadata model that covers this seems like a good idea. >Personally I am glad someone is working on it. I know I am more >concerned with the WG getting the model right then worrying about >specific protocol implementations. > >a. 2004 Message-Id: Date: Tue, 3 Feb 2004 17:25:01 -0500 From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Given that the Fi reference point is explicitly outside of scope ("is not currently defined by the ForCES architecture"), I had assumed that for now the only choice was for FE Y to perform a duplicate lookup. Or, to phrase it differently, I would say that under the current environment FE X would determine that its next hop is FE Y, and FE Y would determine that its next hop is W. It is certainly true that this requires CE configuration of FE X and FE Y. But it does not require or expect any metadata to be passed from FE X to FE Y. In general, given that Fi is outside of scope, I think of all traffic to another FE as if it were to another NE. Yours, Joel M. Halpern At 05:15 PM 2/3/2004 -0500, Steven Blake wrote: >On Tue, 2004-02-03 at 16:56, Joel M. Halpern wrote: > > > Interesting. I had not read your meta-data description as addressing that. > > I had assumed that the only reason for talking about FE-FE level meta-data > > was to make clear it was out of scope. Since packets leaving an FE are > > presumed to be IP packets, I would expect normally want those to be just > > plain vamilla IP packets. > > Some implementations may use the available information to try to do > > something extra. That has been true of all routers. But I would not > > expect it to be within scope for ForCES. > >Ingress FE X receives packet, performs forwarding lookup, determines >packet should exit node on output interface Z on FE Y, via nexthop W. >Packet is forwarded to from FE X to Y. How does FE Y determine Z & W? >o Y performs duplicate forwarding lookup >o Y uses metadata passed from FE X to convey Z & W. > >Either case involves CE-FE configuration on Y. > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure +1 919-472-9913 2004 Message-Id: Date: Tue, 3 Feb 2004 17:15:55 -0500 From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Re: Metadata model for the ForCES model Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Tue, 2004-02-03 at 16:56, Joel M. Halpern wrote: > Interesting. I had not read your meta-data description as addressing that. > I had assumed that the only reason for talking about FE-FE level meta-data > was to make clear it was out of scope. Since packets leaving an FE are > presumed to be IP packets, I would expect normally want those to be just > plain vamilla IP packets. > Some implementations may use the available information to try to do > something extra. That has been true of all routers. But I would not > expect it to be within scope for ForCES. Ingress FE X receives packet, performs forwarding lookup, determines packet should exit node on output interface Z on FE Y, via nexthop W. Packet is forwarded to from FE X to Y. How does FE Y determine Z & W? o Y performs duplicate forwarding lookup o Y uses metadata passed from FE X to convey Z & W. Either case involves CE-FE configuration on Y. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 2004 Message-Id: Date: Tue, 3 Feb 2004 16:56:05 -0500 From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Interesting. I had not read your meta-data description as addressing that. I had assumed that the only reason for talking about FE-FE level meta-data was to make clear it was out of scope. Since packets leaving an FE are presumed to be IP packets, I would expect normally want those to be just plain vamilla IP packets. Some implementations may use the available information to try to do something extra. That has been true of all routers. But I would not expect it to be within scope for ForCES. Yours, Joel M. Halpern At 04:13 PM 2/3/2004 -0500, Zsolt Haraszti wrote: >The consideration I had was that we nail down an >LFB-to-LFB communication model which should be independent of >whether the communicating LFBs are on the same FE or on two or more >separate FEs. This model does not specify how the communication >happens, it only says that if we want to define LFB classes and program >LFBs instance via the ForCES protocol, this is how we have to think >about passing per-packet state from one LFB to another. So, so far >the model text leaves the actual implementation of LFB-to-LFB >communication completely open (well, the ForCES model does not ever >require that LFBs within an FE are implemented as distinct processing >stages...). > >Within an FE I expect that the vendors will always have infinite >freedom how the ForCES model is realized. > >Between FEs's, however, the model does put some requirements on the >implementation. At the minimum, it implies that a certain set of >information (i.e., the set of metadata that is present at the >exit point on FE1 and needed for further processing on FE2) must be >passed _in some way_ between the two FEs. How it is passed is left >to the vendors at this point. One can speculate that many vendors >would benefit from something less proprietary, so I expect that >ForCES will eventually start working on that area. When the work >starts, it will have to take this metadata model into consideration. 2004 Message-Id: Date: Tue, 3 Feb 2004 16:13:59 -0500 From: Zsolt Haraszti Organization: Ericsson IPI Subject: Re: Metadata model for the ForCES model Comments: To: hadi@znyx.com Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Jamal, Thanks for your valuable comments. See my replies embedded. On Sun, 2004-02-01 at 10:14, Jamal Hadi Salim wrote: > Hi Zsolt, > > Some comments: > > + I think with FE-FE metadata we are now treading into FE-FE > domain. I have no problem with this, at least the model related to the > metadata would be good to see in the draft. A lot of chip vendors (and > box vendors) already have protocols implementing interFE metadata > transfers as proprietary - they call them "stacking protocols" > (typically attached to a frame). While it may be too early to get > involved in such a beast, i think it should be put into consideration > (it is only mentioned in passing). Good comment. The consideration I had was that we nail down an LFB-to-LFB communication model which should be independent of whether the communicating LFBs are on the same FE or on two or more separate FEs. This model does not specify how the communication happens, it only says that if we want to define LFB classes and program LFBs instance via the ForCES protocol, this is how we have to think about passing per-packet state from one LFB to another. So, so far the model text leaves the actual implementation of LFB-to-LFB communication completely open (well, the ForCES model does not ever require that LFBs within an FE are implemented as distinct processing stages...). Within an FE I expect that the vendors will always have infinite freedom how the ForCES model is realized. Between FEs's, however, the model does put some requirements on the implementation. At the minimum, it implies that a certain set of information (i.e., the set of metadata that is present at the exit point on FE1 and needed for further processing on FE2) must be passed _in some way_ between the two FEs. How it is passed is left to the vendors at this point. One can speculate that many vendors would benefit from something less proprietary, so I expect that ForCES will eventually start working on that area. When the work starts, it will have to take this metadata model into consideration. > I had a conversation on this in MPLS > with Alan Dekok and wouldnt mind coauthoring a draft with interested > people. I'm sure it will be useful. Let me know if I can help. > > + The first 3 sections are well written > Theres a claim that register based metadata is "more efficient". This > claim is not substantiated in any text. Also not sure why a scheme > on how metadata is _implemented_ needs to be mentioned in a model. > Metadata "moves" with the packet. Model shouldnt care how. OK, the text was written with the primary intent to drive the metadata discussion to a conclusion (first within the model team, then within the ForCES WG), and with the secondary intent to offer text fragments to the new revision of the model draft. But I expect only a portion of this text will go into the revised draft. Much of the motivation/justification text, including the above, will probably not make it. > > + section 4 The Proposed Metadata Model > > - I think a TLV with flags would be appropriately model metadata. > [tag = type; split the type bits into some 4 bits for flags] Your thinking may be to protocol driven. Again, this model--so far-- is mainly to describe a reference model w.r.t. how data passing should be envisioned when defining LFBs, their attributes, and the CE-FE protocol communication. It is not about how to actually pass metadata among LFBs. For the above (reduced) scope, it has some benefits to regard most metadata values as 32 bit integers. BTW, what is the intended usage of the flags? > I also think there is no reason to limit the length to 32 bits > hence the reason a TLV would be a good represantation. See my comments above. > > + section 5 Metadata Production and Consumption > "There may be multiple consumers for the same metadata" > is repeated twice. > - wasnt clear on the "conditional" aspect of metadata; could you provide > a real example? I do not have very strong examples to support this. What I had in mind was cases when the need for a metadata depends on the value of another metadata. For example, one metadata is a RESULTKEY, and another is an ERRORCODE. RESULTKEY is normally used to encode the result of an operation (e.g., a search in a table), and a special value (0) encodes the lack of result. When RESULTKEY=0, then ERRORCODE tells more about the reason of the miss. When RESULTKEY!=0, then ERRORCODE is meaningless, so it can be omitted. I know that this can be done in other ways (embedding the error codes into the RESULTKEY value space; or making ERRORCODE mandatory, but ignore it in downstream LFBs if RESULTKEY!=0, etc.) Once we go through the exercise of creating a library of fully defined LFBs and putting together useful configurations we may conclude that there is no need for this feature. Then we can pull this out. Until then, I left it in a space-holder. But I can be convinced... > > + section 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata > Production > > Isnt the tag selector itself metadata? I think starting this section > you may be treading into implementation specifics. I am disconnected here. Consider an Re-director LFB that can be instantiated to split traffic into multiple streams based on some input metadata. For example, one instance splits based on a classifier key (CLASSID), another splits based on COLOR, a third based on protocolo type (PROTO). This will be realized by an LFB class that will have the following features (simplistic approach): 1) Variable number of outputs 2) An attribute that tells the LFB which metadata tag to look for 3) A table of entries, where each entry will contain a metadata value (as a condition), and a port reference (where to send the packet). So the selector is an attribute of the LFB, read (or possibly written) by the CE via the ForCES protocol. The metadata values of the table entries should be generic enough to accommodate (almost) arbitrary metadata. I see a benefit to make such a field in the table entry a 32-bit integer field (which would serve 95% of the expected metadata types based on our pre-study); that is what motivates to have a generic data type for most metadata. > An LFB should be able to receive a number of metadata and ignore some of > them either based on LFB config or a metadata-selector passed with the > packet. The LFB will use all metadata that is either specified in the LFB specification (XML document) or referred by one of the input metadata tag-selectors. The latter is only applicable to LFB classes that use variable/configurable tag selection. All other metadata will be ignored by the LFB. > > +section 9 Metadata Usage Categories > - "Another way of setting up binding relations is when a > naturally occurring unique identifier of the consumer's object" > What is the event that would cause this? Is it a packet arrival or > a CE reading something off the FE? Let me illustrate what I meant here with an example: Lets say the consumer LFB has a table of things. You may insert a new entry in the table. The operation returns with a table entry index, which can be used in subsequent incremental table management. In the same time, the index can also be used as a way to refer to the given entry from another LFB. E.g, when an upstream LFB wants to refer to one of the table entries, it can send the index in a well-defined metadata. That index is what I consider "naturally occuring," meaning that it exists anyway and it can also be used as a binding metadata. So to answer the original question: the event is a configuration event on the LFB by the CE. > - "The value of the enumerated metadata may or may not be conveyed > via the ForCES protocol between the CE and FE." > > Didnt grasp that. How are LFBs on an FE supposed to cooperate on values > of metadata if they are not synced in this case? Consider a Rate Meter LFB that emits COLOR as metadata. Consider a downstream Rate Meter LFB that uses the COLOR metadata to do further rate metering. To neither of the LFB instances would we ever communicate COLOR as part of the CE-FE communication. It is all built in in the specification of the LFB class and the specification of the COLOR metadata. So this is an example when the enumerated metadata is not conveyed between the CE and FE. Consider now the same Rate Meter LFB emitting the COLOR and a downstream Redirector LFB set up to split the traffic into three paths based on the COLOR. When configuring the Redirector LFB, we would have to tell the LFB to 1) Listen to COLOR metadata 2) Go to port 1, if COLOR=RED, port 2 if YELLOW, and port 3 if GREEN. So in this case we would explicitly convey colors (COLOR values) across the CE-FE interface. > > cheers, > jamal > Thanks for taking your time for going through this. /zsolt > 2004 Message-Id: Date: Tue, 3 Feb 2004 14:57:33 -0800 From: "Putzolu, David" Subject: Interim meeting update (was: RE: [FORCES] Protocol Selection Process: Merger Suggestion) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All,=20 After having reviewed possible dates, venues, and logistics, it appears that an interim ForCES meeting in mid-February is not feasible at this time. Having a ForCES meeting on Sunday, February 29, at the IETF 59 hotel site is still under consideration. A final decision will be forthcoming by this=20 Wednesday. Cheers, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Friday, January 23, 2004 11:05 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Protocol Selection Process: Merger Suggestion > Importance: High >=20 > All, >=20 > After reviewing the protocol submissions it appears that each=20 > of the proposals has valuable features that merit inclusion=20 > in the ForCES protocol. >=20 > Patrick and I would like to urge the various authors to=20 > evaluate whether a merger of the protocols, selecting the=20 > best features of each, would be possible.=20 >=20 > In order to expedite this process we are considering holding=20 > and interim working group meeting two weeks prior to the next=20 > IETF where interested parties could meet for a day to focus=20 > on producing a "best of all worlds" proposal. >=20 > Please contact Patrick or I if you would be interested in=20 > attending such a meeting. >=20 > Thanks, > David & Patrick > co-chairs, IETF ForCES Working Group >=20 2004 Message-Id: Date: Sun, 1 Feb 2004 10:14:30 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Metadata model for the ForCES model Comments: To: Zsolt Haraszti Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi Zsolt, Some comments: + I think with FE-FE metadata we are now treading into FE-FE domain. I have no problem with this, at least the model related to the metadata would be good to see in the draft. A lot of chip vendors (and box vendors) already have protocols implementing interFE metadata transfers as proprietary - they call them "stacking protocols" (typically attached to a frame). While it may be too early to get involved in such a beast, i think it should be put into consideration (it is only mentioned in passing). I had a conversation on this in MPLS with Alan Dekok and wouldnt mind coauthoring a draft with interested people. + The first 3 sections are well written Theres a claim that register based metadata is "more efficient". This claim is not substantiated in any text. Also not sure why a scheme on how metadata is _implemented_ needs to be mentioned in a model. Metadata "moves" with the packet. Model shouldnt care how. + section 4 The Proposed Metadata Model - I think a TLV with flags would be appropriately model metadata. [tag = type; split the type bits into some 4 bits for flags] I also think there is no reason to limit the length to 32 bits hence the reason a TLV would be a good represantation. + section 5 Metadata Production and Consumption "There may be multiple consumers for the same metadata" is repeated twice. - wasnt clear on the "conditional" aspect of metadata; could you provide a real example? + section 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata Production Isnt the tag selector itself metadata? I think starting this section you may be treading into implementation specifics. An LFB should be able to receive a number of metadata and ignore some of them either based on LFB config or a metadata-selector passed with the packet. +section 9 Metadata Usage Categories - "this value also is the value what the metadata carries between the LFBs" ^^^^ ----> should be "that" - "Another way of setting up binding relations is when a naturally occurring unique identifier of the consumer's object" What is the event that would cause this? Is it a packet arrival or a CE reading something off the FE? - "is used as a reference (and as a value" ---> you need to close the brackets - "definiton" typo - "The value of the enumerated metadata may or may not be conveyed via the ForCES protocol between the CE and FE." Didnt grasp that. How are LFBs on an FE supposed to cooperate on values of metadata if they are not synced in this case? cheers, jamal