From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 7 17:47:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13245 for ; Wed, 7 Apr 2004 17:47:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBKtD-0002fL-00 for forces-archive@ietf.org; Wed, 07 Apr 2004 17:47:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBJgL-00064M-00 for forces-archive@ietf.org; Wed, 07 Apr 2004 16:29:58 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BBHZk-0000sY-00 for forces-archive@IETF.ORG; Wed, 07 Apr 2004 14:15:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00D61AD3@cherry.ease.lsoft.com>; Wed, 7 Apr 2004 14:14:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 10501730 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 7 Apr 2004 14:14:58 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Apr 2004 14:08:07 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i37IAO1R024511 for ; Wed, 7 Apr 2004 18:10:25 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i37Hxsbv030704 for ; Wed, 7 Apr 2004 18:00:13 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004040711074407597 for ; Wed, 07 Apr 2004 11:07:44 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 11:07:44 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ForCES Protocol Design Team update - 04/07/2004 Thread-Index: AcQcyzky4VfQpwCoRyaypVxFeYA7uA== X-OriginalArrivalTime: 07 Apr 2004 18:07:44.0757 (UTC) FILETIME=[39D75A50:01C41CCB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Wed, 7 Apr 2004 11:07:44 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Protocol Design Team update - 04/07/2004 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The ForCES protocol team will be using the=20 time line shown below for coming up with the first draft of a ForCES protocol merger proposal. 1.Before April 9th, a. A initial outline done b. decide whether and how we use XML and/or CVS 2.Before April 30th, a. Work out a final and detailed outline, and complete=20 discussion of major issues b. Distribute sections for individual writing 3. a. Complete writing of each sections - May' 20th b. Distribute sections for internal review - May'21st c. Incorporate sections and comments from protocol team - June 1st 4. Send to ForCES mailing list for external review - June 2nd 5. Submission to IETF - June 15th This first draft made available to the ForCES list will be on June 2nd. In the interim, progress may be tracked via the public archives and feedback may be given to the the team via the URL below. http://www.sstanamera.com/~forces/protocoldesignteam.html -David From fby_press@hotmail.com Sat Apr 10 08:20:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03640 for ; Sat, 10 Apr 2004 08:20:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCHTU-0006g7-00 for forces-archive@ietf.org; Sat, 10 Apr 2004 08:20:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCHR8-0006Ld-00 for forces-archive@ietf.org; Sat, 10 Apr 2004 08:18:15 -0400 Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BCHPt-0005qu-00; Sat, 10 Apr 2004 08:16:58 -0400 From: "Atualidade Brasileira . mey" To: enum-request@ietf.org Subject: Livre-comércio: divisor de águas at.: sbd User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 10 Apr 2004 08:16:58 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.2 required=5.0 tests=AWL,HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 AWL AWL: Auto-whitelist adjustment

(ref.:lst) ConstruNews deseja uma Feliz Páscoa a todos os seus amigos e suas respectivas famílias!

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (5)

"Livre-comércio, divisor de águas entre os favoráveis e os contrários à liberdade econômica"

No atual governo brasileiro, o componente ideológico que impregna setores do Itamaraty, regredindo ao terceiro-mundismo dos anos 70, os leva a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos, uma atitude irrealista e até míope, afirma Lindenberg em recente artigo

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fóruns Sociais. Assim, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Em seu recente artigo "A economia de mercado e o livre-comércio", da Série Temas Patrulhados, o autor lamenta que a economia de mercado e o livre-comércio continuem sendo o alvo predileto da dialética intervencionista e progressista. Os argumentos usados se repetem como certas melodias dos clássicos realejos de antigamente, comenta Lindenberg, que em seu artigo enumera uma série dessas diatribes, das quais citamos aqui:

- Livres de quaisquer tabelamento ou fiscalização de "órgãos competentes", os preços subiriam assustadoramente, empobrecendo os consumidores, deixando-os indefesos diante da ganância dos industriais, fazendeiros, comerciantes, etc.

- A ganância dos industriais e o esmagamento das pequenas empresas incapazes de competir contra os gigantes empresariais, só sofreriam limites se o Estado intervier no mercado, via controle de preços, estatização das empresas de serviços públicos, subsídios e barreiras alfandegárias.

- O livre-comércio seria a porta de entrada dos produtos das multinacionais em nosso país com o intuito de nos explorar e nos submeter ao imperialismo norte-americano.

* A estas e outras diatribes analisadas e refutadas no artigo, se soma, no atual governo brasileiro, o componente ideológico que passou a impregnar setores do Itamaraty, parecendo ter regredido ao terceiro-mundismo dos anos 70, dispostos a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos. Atitude de nossa diplomacia que tem sido qualificada de "irrealista" por analistas políticos e criticada enfaticamente.

* A única correção possível para essa miopia consiste numa boa compreensão do que seja uma concorrência sadia e de como a competitividade entre os produtores constitui o instrumento natural para manter os preços dos produtos pouco acima de seu preço de custo, explica Lindenberg.

* O mercado é uma realidade funcional que oferece condições para produtores e consumidores, vendedores e compradores entrarem em contato entre si, com vistas a conhecer, avaliar e comparar os bens oferecidos e eventualmente chegar a acordos sobre preços. Tais combinações são obtidas mediante o livre jogo da oferta e da procura.

* Todos quantos consideram preferível a determinação dos preços por via governamental - evitando destarte os "desmandos da lei da oferta e da procura" - por mais bem-intencionados que possam ser (requisito não muito comum em nossos dias...), por melhores que sejam os programas de seus computadores, nunca conseguirão combinar as centenas de fatores que condicionam os preços de um modo tão perfeito, vivo e atualizado, como aqueles que emergem das práticas mercadológicas.

* A aceitação ou recusa do livre-comércio e suas conseqüências naturais, é o divisor de águas entre as mentalidades favoráveis e as contrárias à liberdade econômica, conclui Lindenberg, cujo artigo oferecemos gratuitamente.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: EsteArtigoCompletoGratuitamente(No.5)

Outros links gratuitos (e-Book e outros artigos):

e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

 Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:MinhaOpinião

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 

 From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 14 18:18:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02566 for ; Wed, 14 Apr 2004 18:18:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsiI-0001r1-00 for forces-archive@ietf.org; Wed, 14 Apr 2004 18:18:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDshK-0001lv-00 for forces-archive@ietf.org; Wed, 14 Apr 2004 18:17:35 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BDsgR-0001gq-00 for forces-archive@IETF.ORG; Wed, 14 Apr 2004 18:16:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00D6E153@cherry.ease.lsoft.com>; Wed, 14 Apr 2004 18:16:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 11629138 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Apr 2004 18:16:33 -0400 Approved-By: zsolt.haraszti@ERICSSON.COM Received: from 198.24.6.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Apr 2004 18:15:57 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i3EMFpLc005801 for ; Wed, 14 Apr 2004 17:15:51 -0500 (CDT) Received: from empress.ipi.us.am.ericsson.se (147.117.169.67 [147.117.169.67]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 23S92DR5; Wed, 14 Apr 2004 17:15:43 -0500 Content-Type: multipart/mixed; boundary="=-H4TJkYksSETXxcz8Qm0M" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Message-ID: <1081980939.5813.493.camel@empress.ipi.us.am.ericsson.se> Date: Wed, 14 Apr 2004 18:15:39 -0400 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IP Infrastructure Subject: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 --=-H4TJkYksSETXxcz8Qm0M Content-Type: text/plain Content-Transfer-Encoding: 7bit After the dissemination of the last model draft in February (draft-ietf-forces-model-02.txt), we got many very useful comments. Thanks. One topic that generated lots of questions was the concept of LFB inputs and outputs. It became obvious to us that in 02 we did not do a good job explaining the proposed LFB input/output model. Attached is a fully revised version of the relevant subsections of 02 (3.2.1 and 3.2.2). Hopefully this text conveys the design intent much better. Comments are welcome! -- Zsolt Haraszti, Ph.D. Tel: +1 919 472 9949 Ericsson IP Infrastructure Fax: +1 919 472 9999 Raleigh NC USA Email: zsolt.haraszti@ericsson.com --=-H4TJkYksSETXxcz8Qm0M Content-Disposition: attachment; filename=in_out_group_3.txt Content-Type: text/plain; name=in_out_group_3.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 3.2.1. LFB Outputs A LFB output is a conceptual port on a LFB that can send information to some other LFB. The information is typically a packet and associated metadata, although in some cases it might consist of only metadata, i.e., with no packet data. A single LFB output can be connected to only one LFB input. This is required to make the packet flow through the LFB topology unambiguous. Some LFBs will have a single output, as depicted in Figure 3.a. +---------------+ +-----------------+ | | | | | | | OUT +--> ... OUT +--> ... | | | | EXCEPTIONOUT +--> | | | | +---------------+ +-----------------+ a. One output b. Two distinct outputs +---------------+ +-----------------+ | | | EXCEPTIONOUT +--> | OUT:1 +--> | | ... OUT:2 +--> ... OUT:1 +--> | ... +... | OUT:2 +--> | OUT:n +--> | ... +... +---------------+ | OUT:n +--> +-----------------+ c. One output group d. One output and one output group Figure 3. Examples of LFBs with various output combinations. To accommodate any non-trivial LFB topology, multiple LFB outputs must be allowed so that a LFB class can fork the datapath. Two mechanisms are provided for forking: multiple singleton outputs and output groups (the two concepts can be also combined in the same LFB class). Multiple separate singleton outputs are defined in a LFB class to model a pre-determined number of semantically different outputs. Pre-determined here means that the number of outputs are known at the time when the LFB class is defined. Additional singleton outputs cannot be created at LFB instantiation time, neither can they be created on the fly after the LFB is instantiated. For example, an IPv4 LPM (Longest-Prefix-Matching) LFB may have one output (OUT) to send those packets for which LPM look-up was successful (passing a META_ROUTEID as metadata); and have another output (EXCEPTIONOUT) for sending exception packets for which the LPM look-up failed. This example is depicted in Figure 3.b. Packets emitted by these two outputs not only require very different downstream treatment, but they are a result of two very different conditions in the LFB, and they also carry different metadata. This concept assumes that the number of distinct outputs are known at the time of LFB class definition. For each singleton output the LFB class definition defines what types of frames and metadata the output emits. An output group, on the other hand, is used to model the case where a flow of seemingly similar packets with an identical set of metadata need to be split into multiple paths, and where the number of such paths is not known when the LFB class if defined (i.e., because it is not an inherent property of the LFB class). An output group consists of a number of outputs (called the output instances of the group), all sharing the same frame and metadata emission definitions (see Figure 3.c). Each output instance can connect to a different downstream LFB, just as if they were separate singleton outputs. But, in contrast with the singleton outputs, the number of output instances can be different from one instance of the LFB class to another. The class definition may include a lower and/or an upper limit on the number of output instances. In addition, for configurable FEs, the FE capability information may include further limits on the number of instances in specific output groups of certain LFBs. The actual number of output instances in a group is an attribute of the LFB instance, which is read-only for static topologies, and read-write for dynamic topologies. The output instances in a group are numbered sequentially, from 0 to N-1, and are addressable from within the LFB. The LFB has a built-in mechanism to select one specific output instance for each packet. This mechanism is well described in the textual definition of the class and it is typically configurable via some attributes of the LFB. For example, consider a re-director LFB, whose sole purpose is to direct packets to one of N downstream paths based on one of the metadata associated with each arriving packet. Such a LFB is fairly versatile and can be used in many different places in a topology, for example to divide the data path into an IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork into color specific paths after metering using the COLOR metadata (red, yellow, green; N=3), etc. Using an output group in the above LFB class provides the desired flexibility to adapt each instance of this class to the required operation. The metadata which is to be used as a selector for the output instance is a property of the LFB. For each packet, the value of the specified metadata may be used as a direct index to the output instance. Alternatively, the LFB may have a configurable selector table that maps a metadata value to output instance. Note that other LFBs may also use the concept of output group to build in similar adaptive forking capability. For example, a classifier LFB with one input and N outputs can be defined easily by using the output group concept. Alternatively, a classifier LFB with one singleton output in combination with an explciit N-output re-director LFB to model the same processing behavior. The decision of whether to use the output group model for a certain LFB class is left to the LFB class designers. The model allows the output group be combined with other singleton output(s) in the same class, as it is demonstrated in Figure 3.d. The LFB here has two types of outputs, OUT for normal packet output, and EXCEPTIONOUT for packets that triggered some exception. The normal OUT has multiple instances, i.e., it is an output group. In summary, the LFB class may define one output, multiple singleton outputs, one or more output groups, or a combination of the latter two. Multiple singleton outputs are to be used when the LFB must provide for forking the datapath, and at least one of the following conditions hold: - the number of downstream directions are inherent from the definition of the class (and hence fixed); - the frame type and set of metadata emitted on any of the outputs are substantially different from what is emitted on the other outputs (i.e., they cannot share frame-type and metadata definitions); An output group is appropriate when the LFB must provide for forking the datapath, and at least one of the following conditions hold: - the number of downstream directions is not known when the LFB class is defined (i.e., because it is not an inherent property of the class); - the frame type and set of metadata emitted on these outputs are sufficiently similar or identical, so they can share the same output definition. 3.2.2. LFB Inputs A LFB input is a conceptual port on a LFB where the LFB can receive information from other LFBs. The information is typically a packet and associated metadata, although in some cases it might consist of only metadata, i.e., with no packet data. It is nevertheless inevitable that there will be LFB instances that will receive packets from more than one other LFB instance (fan-in). There are three ways of modeling the fan-in, all supported in the LFB model: - Implicit multiplexing via a single input - Explicit multiplexing via multiple singleton inputs - Explicit multiplexing via a group of inputs (input group) The above modes can be combined in the same LFB. The simplest form of multiplexing uses a singleton input (Figure 4.a). It is in fact expected that most LFBs will have only one singleton input. Multiplexing into a single input is possible because the model allows for more than one LFB output to connect to the same input of an LFB. This property applies to any LFB input without any special provisioning in the LFB class. Multiplexing into a single input is applicable when the packets from the upstream LFBs are similar (in frame-type and accompanying metadata) and require similar processing. Note that this model does not address how potential contention is handled when multiple packets arrive simultaneously. If this needs to be explicitly modeled, one of the other two modeling solutions must be used. The second method to model fan-in uses separately defined singleton inputs (Figure 4.b). This model is meant for situations where the LFB needs to handle distinct types of packet streams, requiring input-specific handling inside the LFB, and where the number of such distinct cases is an inherent property of the LFB class (and hence is known when the LFB class is defined). For example, a Layer 2 Decapsulation/Encapsulation LFB may have two inputs, one for receiving Layer 2 frames for decapsulation, and one for receiving Layer 3 frames for encapsulation. Such a LFB would expect very different frames (L2 vs. L3) at its inputs, each with different sets of metadata, and would obviously apply different processing on frames arriving at these inputs. This model is capable of explicitly addressing packet contention, i.e., by defining how the LFB class handles the contending packets. +--------------+ +------------------------+ | LFB X +---+ | | +--------------+ | | | | | | +--------------+ v | | | LFB Y +---+-->|input Meter LFB | +--------------+ ^ | | | | | +--------------+ | | | | LFB Z |---+ | | +--------------+ +------------------------+ (a) A LFB connects with multiple upstream LFBs via a single input. +--------------+ +------------------------+ | LFB X +---+ | | +--------------+ +-->|layer2 | +--------------+ | | | LFB Y +------>|layer3 LFB | +--------------+ +------------------------+ (b) A LFB connects with multiple upstream LFBs via two separate singleton inputs. +--------------+ +------------------------+ | Queue LFB #1 +---+ | | +--------------+ | | | | | | +--------------+ +-->|in:0 \ | | Queue LFB #2 +------>|in:1 | input group | +--------------+ |... | | +-->|in:N-1 / | ... | | | +--------------+ | | | | Queue LFB #N |---+ | Scheduler LFB | +--------------+ +------------------------+ (c) A Scheduler LFB uses an input group to differentiate which queue LFB packets are coming from. Figure 3. Input modeling concepts (examples). The third method to model fan-in uses the concept of an input group. The concept is similar to the output group introduced in the previous section, and is depicted in Figure 4.c. An input group consists of a number of input instances, all sharing the properties (same frame and metadata expectations). The input instances are numbered from 0 to N-1. From the outside these inputs appear as normal inputs, i.e., any compatible upstream LFB can connect its output to one of these inputs. When a packet is presented to the LFB at a particular input instance, the index of the input where the packet arrived will be known to the LFB and this information may be used in the internal processing. For example, the input index can be used as a table selector, or as an explicit precedence selector to resolve contentions. As with output groups, the number of input instances in an input group is not defined in the LFB class, though the class definition may include restrictions on the range of possible values. In addition, if a FE supports configurable topologies, it may impose further limitations on the number of instances for a particular port group(s) of a particular LFB class. Within these limitations, different instances of the same class may have a different number of input instances. The number of actual input instances in the group is an attribute of the LFB class, which is read-only for static topologies, and it is read-write for configurable topologies. As an example for the input group, consider the Scheduler LFB depicted in Figure 3.c. Such an LFB receives packets from a number of Queue LFBs via a number of input instances, and uses the input index information to control contention resolution and scheduling. In summary, the LFB class may define one input, multiple singleton inputs, one or more input groups, or a combination thereof. Any input allows for implicit multiplexing of similar packet streams via connecting multiple outputs to the same input. Explicit multiple singleton inputs are useful when either the contention handling must be handled explicitly, or when the LFB class must receive and process a known number of very distinct types of packet streams. An input group is suitable when the contention handling must be modeled explicitly, but the number of inputs are not inherent from the class (and hence not known when the class is defined), or when it is critical for LFB operation to know exactly which input the packet was received. --=-H4TJkYksSETXxcz8Qm0M-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 20 19:07:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05838 for ; Tue, 20 Apr 2004 19:07:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG4Kq-0002gM-VK for forces-archive@ietf.org; Tue, 20 Apr 2004 19:07:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4Jo-0002cw-00 for forces-archive@ietf.org; Tue, 20 Apr 2004 19:06:21 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BG4Jd-0002Zi-00 for forces-archive@IETF.ORG; Tue, 20 Apr 2004 19:06:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00D7A2B4@cherry.ease.lsoft.com>; Tue, 20 Apr 2004 19:06:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 12640039 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Apr 2004 19:06:03 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Apr 2004 18:54:31 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3KMsUkA007956; Tue, 20 Apr 2004 22:54:31 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3KMqSRo022237; Tue, 20 Apr 2004 22:54:26 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042015541805603 ; Tue, 20 Apr 2004 15:54:18 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 15:54:18 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Revised LFB input/output text Thread-Index: AcQibixYBJLlIl/7R2imFhFxHVgAxwEvCyYg X-OriginalArrivalTime: 20 Apr 2004 22:54:18.0155 (UTC) FILETIME=[69466FB0:01C4272A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Tue, 20 Apr 2004 15:54:17 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Revised LFB input/output text Comments: To: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Zsolt. This looks much better and makes sense to me now. Minor nit: Should be ragged-right justification when it is actually added to the model draft. Cheers, David =20 > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti > Sent: Wednesday, April 14, 2004 3:16 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Revised LFB input/output text >=20 > After the dissemination of the last model draft in February > (draft-ietf-forces-model-02.txt), we got many very useful > comments. Thanks. One topic that generated lots of questions > was the concept of LFB inputs and outputs. It became obvious > to us that in 02 we did not do a good job explaining the proposed > LFB input/output model. >=20 > Attached is a fully revised version of the relevant subsections > of 02 (3.2.1 and 3.2.2). Hopefully this text conveys the design > intent much better. >=20 > Comments are welcome! >=20 > -- > Zsolt Haraszti, Ph.D. Tel: +1=20 > 919 472 9949 > Ericsson IP Infrastructure Fax: +1=20 > 919 472 9999 > Raleigh NC USA Email:=20 > zsolt.haraszti@ericsson.com >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 20 19:21:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06340 for ; Tue, 20 Apr 2004 19:21:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG4YD-0003bX-Ln for forces-archive@ietf.org; Tue, 20 Apr 2004 19:21:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4XF-0003Y9-00 for forces-archive@ietf.org; Tue, 20 Apr 2004 19:20:13 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BG4WH-0003Ut-00 for forces-archive@IETF.ORG; Tue, 20 Apr 2004 19:19:13 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00D7A255@cherry.ease.lsoft.com>; Tue, 20 Apr 2004 19:19:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 12641401 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 20 Apr 2004 19:19:12 -0400 Approved-By: lily.l.yang@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 Apr 2004 19:16:45 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3KNGkkA023806; Tue, 20 Apr 2004 23:16:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3KNGcRG005495; Tue, 20 Apr 2004 23:16:43 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042016163528860 ; Tue, 20 Apr 2004 16:16:35 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 16:16:35 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Revised LFB input/output text Thread-Index: AcQibixYBJLlIl/7R2imFhFxHVgAxwEvCyYgAAClkBA= X-OriginalArrivalTime: 20 Apr 2004 23:16:35.0866 (UTC) FILETIME=[869CEFA0:01C4272D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE5C426D@orsmsx408.jf.intel.com> Date: Tue, 20 Apr 2004 16:16:35 -0700 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Revised LFB input/output text Comments: To: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Jamal -- I promised that I will get back to you on the confusion over = input/output group concept. If you have not done so, I would encourage = you read over the new text Zsotl sent out. I hope that address the = issues for you. If not, please let us know. Thanks for your earlier comments. That really help the model team to dig = deeper into the subject and come up with this new (and better, in my = opinion) text.=20 Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Putzolu, David > Sent: Tuesday, April 20, 2004 3:54 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Revised LFB input/output text >=20 >=20 > Hi Zsolt. >=20 > This looks much better and makes sense to me now. >=20 > Minor nit: Should be ragged-right justification when > it is actually added to the model draft. >=20 > Cheers, > David > =20 >=20 > > -----Original Message----- > > From: Forwarding and Control Element Separation=20 > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti > > Sent: Wednesday, April 14, 2004 3:16 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] Revised LFB input/output text > >=20 > > After the dissemination of the last model draft in February > > (draft-ietf-forces-model-02.txt), we got many very useful > > comments. Thanks. One topic that generated lots of questions > > was the concept of LFB inputs and outputs. It became obvious > > to us that in 02 we did not do a good job explaining the proposed > > LFB input/output model. > >=20 > > Attached is a fully revised version of the relevant subsections > > of 02 (3.2.1 and 3.2.2). Hopefully this text conveys the design > > intent much better. > >=20 > > Comments are welcome! > >=20 > > -- > > Zsolt Haraszti, Ph.D. Tel: +1=20 > > 919 472 9949 > > Ericsson IP Infrastructure Fax: +1=20 > > 919 472 9999 > > Raleigh NC USA Email:=20 > > zsolt.haraszti@ericsson.com > >=20 > >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 22 12:19:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08140 for ; Thu, 22 Apr 2004 12:19:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgv2-00057y-Dr for forces-archive@ietf.org; Thu, 22 Apr 2004 12:19:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgu3-0004qx-00 for forces-archive@ietf.org; Thu, 22 Apr 2004 12:18:19 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BGgtS-0004Zr-00 for forces-archive@IETF.ORG; Thu, 22 Apr 2004 12:17:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00D7E1ED@cherry.ease.lsoft.com>; Thu, 22 Apr 2004 12:17:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 12972122 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Apr 2004 12:17:38 -0400 Approved-By: gamil.cain@INTEL.COM Received: from 192.55.52.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 Apr 2004 12:16:12 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3MGGKri000806; Thu, 22 Apr 2004 16:16:20 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3MGGC8M028759; Thu, 22 Apr 2004 16:16:14 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042209160405116 ; Thu, 22 Apr 2004 09:16:04 -0700 Received: from fmsmsx405.amr.corp.intel.com ([132.233.42.209]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 09:16:04 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Revised LFB input/output text Thread-Index: AcQibi3NVF3iPfacR2qvpjhANUzcDAGEp4eg X-OriginalArrivalTime: 22 Apr 2004 16:16:04.0624 (UTC) FILETIME=[1C727100:01C42885] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <89597CBB41D2094A81EAD6C801D5322104A9012D@fmsmsx405.fm.intel.com> Date: Thu, 22 Apr 2004 09:16:04 -0700 Reply-To: "Cain, Gamil" Sender: Forwarding and Control Element Separation From: "Cain, Gamil" Subject: Re: Revised LFB input/output text Comments: To: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Zsolt, Finally getting around to reviewing this text. It is much improved!!! Thanks. Just a clarification. The concept of a group is really used to allow certain variance in the *instantiations* of a particular LFB class. An instantiation of a particular LFB class may (or may not) only set certain upper and lower bounds on the number of ports contained in a group, via it's attributes. The group concept does not allow an instantiation of a class to dynamically grow/shrink the number of ports in an output group beyond what can be specified by it's attributes. Is this a correct understanding? Along the same lines, there is a sentence in the text that states: "The number of actual input instances in the group is an attribute of the LFB class, which is read-only for static topologies, and it is read-write for configurable topologies." Shouldn't that say the input instances in the group are an attribute of an *instance* of an LFB class? Regards, Gamil. 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 Zsolt Haraszti >Sent: Wednesday, April 14, 2004 3:16 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Revised LFB input/output text > >After the dissemination of the last model draft in February >(draft-ietf-forces-model-02.txt), we got many very useful >comments. Thanks. One topic that generated lots of questions >was the concept of LFB inputs and outputs. It became obvious >to us that in 02 we did not do a good job explaining the proposed >LFB input/output model. > >Attached is a fully revised version of the relevant subsections >of 02 (3.2.1 and 3.2.2). Hopefully this text conveys the design >intent much better. > >Comments are welcome! > >-- >Zsolt Haraszti, Ph.D. Tel: +1 919 472 9949 >Ericsson IP Infrastructure Fax: +1 919 472 9999 >Raleigh NC USA Email: zsolt.haraszti@ericsson.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 22 20:52:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15942 for ; Thu, 22 Apr 2004 20:52:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGova-00049M-0c for forces-archive@ietf.org; Thu, 22 Apr 2004 20:52:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoug-0003uG-00 for forces-archive@ietf.org; Thu, 22 Apr 2004 20:51:30 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BGou6-0003f1-00 for forces-archive@IETF.ORG; Thu, 22 Apr 2004 20:50:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00D7EFF9@cherry.ease.lsoft.com>; Thu, 22 Apr 2004 20:50:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 13030500 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 22 Apr 2004 20:50:50 -0400 Approved-By: lily.l.yang@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 Apr 2004 20:50:24 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3N0oW88029375 for ; Fri, 23 Apr 2004 00:50:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3N0mRkN005695 for ; Fri, 23 Apr 2004 00:49:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042217502002254 for ; Thu, 22 Apr 2004 17:50:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 17:50:19 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Revised LFB input/output text Thread-Index: AcQibi3NVF3iPfacR2qvpjhANUzcDAGEp4egABMCNCA= X-OriginalArrivalTime: 23 Apr 2004 00:50:19.0849 (UTC) FILETIME=[F3982390:01C428CC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42A4@orsmsx408.jf.intel.com> Date: Thu, 22 Apr 2004 17:50:19 -0700 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Revised LFB input/output text Comments: To: "Cain, Gamil" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable See below for my own understanding. I am sure Zsolt will correct me if I = get it wrong. > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Cain, Gamil > Sent: Thursday, April 22, 2004 9:16 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Revised LFB input/output text >=20 >=20 > Zsolt, >=20 > Finally getting around to reviewing this text. It is much improved!!! > Thanks. >=20 > Just a clarification. The concept of a group is really used to allow > certain variance in the *instantiations* of a particular LFB=20 > class. An > instantiation of a particular LFB class may (or may not) only set > certain upper and lower bounds on the number of ports contained in a > group, via it's attributes. The group concept does not allow an > instantiation of a class to dynamically grow/shrink the=20 > number of ports > in an output group beyond what can be specified by it's=20 > attributes. Is > this a correct understanding? YES. >=20 > Along the same lines, there is a sentence in the text that states: >=20 > "The number of actual input instances in the group is an=20 > attribute of > the LFB class, which is read-only for static topologies, and it > is read-write for configurable topologies." >=20 > Shouldn't that say the input instances in the group are an=20 > attribute of > an *instance* of an LFB class? YES. >=20 >=20 > Regards, >=20 > Gamil. >=20 >=20 >=20 > Gamil Cain > Software Architect > Intel Research & Development > 916.356.9153 > mailto:gamil.cain@intel.com > =20 >=20 > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti > >Sent: Wednesday, April 14, 2004 3:16 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Revised LFB input/output text > > > >After the dissemination of the last model draft in February > >(draft-ietf-forces-model-02.txt), we got many very useful > >comments. Thanks. One topic that generated lots of questions > >was the concept of LFB inputs and outputs. It became obvious > >to us that in 02 we did not do a good job explaining the proposed > >LFB input/output model. > > > >Attached is a fully revised version of the relevant subsections > >of 02 (3.2.1 and 3.2.2). Hopefully this text conveys the design > >intent much better. > > > >Comments are welcome! > > > >-- > >Zsolt Haraszti, Ph.D. Tel: +1=20 > 919 472 9949 > >Ericsson IP Infrastructure Fax: +1=20 > 919 472 9999 > >Raleigh NC USA Email:=20 > zsolt.haraszti@ericsson.com >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 27 10:16:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03077 for ; Tue, 27 Apr 2004 10:16:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITOM-0001xq-Nz for forces-archive@ietf.org; Tue, 27 Apr 2004 10:16:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITNW-0001va-00 for forces-archive@ietf.org; Tue, 27 Apr 2004 10:16:06 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BITN7-0001si-00 for forces-archive@IETF.ORG; Tue, 27 Apr 2004 10:15:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00D87FBC@cherry.ease.lsoft.com>; Tue, 27 Apr 2004 10:15:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 13785992 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 27 Apr 2004 10:15:40 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Apr 2004 09:37:37 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042706405859:13428 ; Tue, 27 Apr 2004 06:40:58 -0700 References: <2AF68A477DD44C4EBCBE338C24E7A9EE5C426D@orsmsx408.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 06:40:59 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 06:41:01 AM, Serialize complete at 04/27/2004 06:41:01 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083073053.10438.192.camel@jzny.localdomain> Date: Tue, 27 Apr 2004 09:37:33 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Revised LFB input/output text Comments: To: "Yang, Lily L" Comments: cc: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE5C426D@orsmsx408.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Lily, Zsolt, On Tue, 2004-04-20 at 19:16, Yang, Lily L wrote: > Hi, Jamal -- > > I promised that I will get back to you on the confusion over > input/output group concept. If you have not done so, I would > encourage you read over the new text Zsotl sent out. I hope > that address the issues for you. If not, please let us know. > Where is the text on the metadata? ;-> I finaly got to reading this. To be honest, i wouldnt say i am thrilled although i would say there is an improvement. As an example, the input grouping(section 3.2.2. LFB Inputs) with the three alternatives offered is a good approach because it doesnt lean on one thing only and rather points the alternative. The danger with model drafts is that people with weak minds (who may take the shape of customers) will end up taking them literally in 3 years after publication. Iam trying hard to make it fit my mental view of things. Maybe i should explain my view of the world then lets see if theres a middle ground view which doesnt leave it out. So in my world (as the expedia commercial starts) there are no input or output groups. Let me throw in a diagram to clarify. +--------------+ +------------------+ | LFB X +---+ | | +--------------+ +--------------+ | | | +-->| LFB A | | | | | +--------------+ .... ... . ... .. .| | | +-->|input LFB | | . .. . ... ... .^ | +->+-----> Default/exception | | | | +--------------+ | | | . | LFB Z |---+ | | . +--------------+ +------------------+ +----------> LFB D 1) There is only one input. This is at least taken care of by the section 3.2.2 example (a) so i am not gonna whine about it. 2) There may be multiple edges (emanating from other LFBs or nodes) that may lead to this input 3) There may be several branches of execution within an LFB 4) Input data or metadata decides on the processing within an LFB path taken. 5) There may be multiple output paths from an LFB 6) Processing results which may consult state decide on the output edge/branch to take. 7) metadata may be encoded as a result of #6 above in order to influence nexthop LFB processing (as described in #4 above) On the nature of the output branching: There is no restriction on where those branches go. They may loop back to self. Now lets take the four examples listed.o +---------------+ +-----------------+ | | | | | | | OUT +--> ... OUT +--> ... | | | | EXCEPTIONOUT +--> | | | | +---------------+ +-----------------+ a. One output b. Two distinct outputs I see no difference between the two. One has two branches and the otehr has one. +---------------+ +-----------------+ | | | EXCEPTIONOUT +--> | OUT:1 +--> | | ... OUT:2 +--> ... OUT:1 +--> | ... +... | OUT:2 +--> | OUT:n +--> | ... +... +---------------+ | OUT:n +--> +-----------------+ c. One output group d. One output and one output group Again i see no difference of these from the general model above. The contendig issue seems to be that in c. and d. you can keep adding these output branches to the LFB instance. Sure, depending on the capability of the LFB thats just fine; you should be able to edit its runtime properties and add more branches. I have to run to work, hopefully that gets my concerns across. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 27 12:35:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10697 for ; Tue, 27 Apr 2004 12:35:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVXx-0002Ks-Hf for forces-archive@ietf.org; Tue, 27 Apr 2004 12:35:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVX1-0002Gk-00 for forces-archive@ietf.org; Tue, 27 Apr 2004 12:34:03 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BIVWL-0002DR-00 for forces-archive@IETF.ORG; Tue, 27 Apr 2004 12:33:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00D8828F@cherry.ease.lsoft.com>; Tue, 27 Apr 2004 12:33:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 13802250 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 27 Apr 2004 12:33:17 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Apr 2004 12:32:41 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3RGWjf0030673 for ; Tue, 27 Apr 2004 16:32:46 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3RGUhmj031026 for ; Tue, 27 Apr 2004 16:32:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042709323628265 for ; Tue, 27 Apr 2004 09:32:36 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 09:32:36 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Change to ForCES List Moderation Policy Thread-Index: AcQsdT9SIq5OHmx0QHm08HHXwM8C/A== X-OriginalArrivalTime: 27 Apr 2004 16:32:36.0344 (UTC) FILETIME=[3F9FA780:01C42C75] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Tue, 27 Apr 2004 09:32:36 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Change to ForCES List Moderation Policy To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, Due to the high volume of non-subscriber spam, the ForCES list configuration is being changed as follows. - Previously non-subscriber mail was reviewed by the chairs and forwarded if appropriate + Going forward, non-subscriber mail will be automatically rejected. Non-subscribers must contact me or Patrick=20 (dro@zurich.ibm.com) directly to have their email=20 forwarded to the list. Handling of subscriber posts remains unchanged, that is, all subscriber posts are verified via a nonce to the sender, then posted to the list. The ForCES mailing list moderation policy is fully explained at: http://www.sstanamera.com/~forces/mailing.html -David From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 27 18:50:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08678 for ; Tue, 27 Apr 2004 18:50:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbP1-00070c-Ai for forces-archive@ietf.org; Tue, 27 Apr 2004 18:50:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbO2-0006uP-00 for forces-archive@ietf.org; Tue, 27 Apr 2004 18:49:11 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BIbN4-0006jS-00 for forces-archive@IETF.ORG; Tue, 27 Apr 2004 18:48:10 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00D88E6E@cherry.ease.lsoft.com>; Tue, 27 Apr 2004 18:48:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 13842740 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 27 Apr 2004 18:48:05 -0400 Approved-By: lily.l.yang@INTEL.COM Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Apr 2004 18:40:34 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3RMeTZu009222; Tue, 27 Apr 2004 22:40:29 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3RMbmnZ001632; Tue, 27 Apr 2004 22:40:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042715402020183 ; Tue, 27 Apr 2004 15:40:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 15:40:20 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Revised LFB input/output text Thread-Index: AcQsYiNuIOLwv2a2RpudkEH1dXQE6QAP8HjA X-OriginalArrivalTime: 27 Apr 2004 22:40:20.0355 (UTC) FILETIME=[9ECC8D30:01C42CA8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> Date: Tue, 27 Apr 2004 15:40:16 -0700 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jamal -- The key difference I see in your view and the view described in the = model document is regarding the output branching -- everything else you = said seem in sync with the model we have in mind. In your description: > 5) There may be multiple output paths from an LFB > 6) Processing results which may consult state decide on the output > edge/branch to take. > 7) metadata may be encoded as a result of #6 above in order to > influence nexthop LFB processing (as described in #4 above) I understand that the branching is driven by the "metadata". But we need = to explicitly model that behavior somewhere in this graph.=20 And the picture you drew shows that one output from LFB can branch into = several different LFB for next step of processing. It is not clear to me = where/how the "metadata driven branching" is modeled.=20 That kind of branching is prohibited explicitly in our current model = with a good reason: "A single LFB output can be connected to only one LFB input. This is required to make the packet flow through the LFB topology unambiguous." A simple way to model that behavior would be inserting a "redirector" = LFB between the output branch and the multiple next step LFBs. The = "redirector" LFB has one input and multiple output, and the only = processing it does is to send packets to different output according to = the metadata.=20 So all in all, what you want is indeed provided by the current model -- = as long as you explictly model them. Another thing you said which I don't quite agree is that you don't see = any difference in example a) and b). If the LFB to be modeled tend to = process the packets and sort them into two different categories -- then = we should model them explicitly within the LFB and the multiple outputs = enable just that -- the semantic difference between the two outputs. Granted, just because we provide all these mechanisms/alternatives, it = doesn't mean every LFB designer has to use it for every LFB. I tend to = think of what FE model provides as what C language provides. You can = choose to use array, struct to make your program more readable, more = elegant. But you can also choose ignore all that, just use simple scalar = variables to do everything -- it is probably still doable, = theoretically. But there are times when you realize it definetely makes = big difference if you use the right constructs. Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Tuesday, April 27, 2004 6:38 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Revised LFB input/output text >=20 >=20 > Lily, Zsolt, >=20 > On Tue, 2004-04-20 at 19:16, Yang, Lily L wrote: > > Hi, Jamal -- > > > > I promised that I will get back to you on the confusion over > > input/output group concept. If you have not done so, I would > > encourage you read over the new text Zsotl sent out. I hope > > that address the issues for you. If not, please let us know. > > >=20 > Where is the text on the metadata? ;-> > I finaly got to reading this. To be honest, i wouldnt say i=20 > am thrilled > although i would say there is an improvement. As an example, the input > grouping(section 3.2.2. LFB Inputs) with the three=20 > alternatives offered > is a good approach because it doesnt lean on one thing only and rather > points the alternative. The danger with model drafts is that people > with weak minds (who may take the shape of customers) will=20 > end up taking > them literally in 3 years after publication. > Iam trying hard to make it fit my mental view of things.=20 > Maybe i should > explain my view of the world then lets see if theres a middle ground > view which doesnt leave it out. > So in my world (as the expedia commercial starts) there are=20 > no input or > output groups. > Let me throw in a diagram to clarify. >=20 > +--------------+ +------------------+ > | LFB X +---+ | | =20 > +--------------+ > +--------------+ | | | +-->| LFB=20 > A | > | | | | =20 > +--------------+ > .... ... . ... .. .| | | > +-->|input LFB | | > . .. . ... ... .^ | +->+-----> > Default/exception > | | | | > +--------------+ | | | . > | LFB Z |---+ | | . > +--------------+ +------------------+ +----------> LFB D >=20 >=20 > 1) There is only one input. This is at least taken care of by the > section 3.2.2 example (a) so i am not gonna whine about it. > 2) There may be multiple edges (emanating from other LFBs or nodes) > that may lead to this input > 3) There may be several branches of execution within an LFB > 4) Input data or metadata decides on the processing within > an LFB path taken. > 5) There may be multiple output paths from an LFB > 6) Processing results which may consult state decide on the output > edge/branch to take. > 7) metadata may be encoded as a result of #6 above in order to > influence nexthop LFB processing (as described in #4 above) >=20 > On the nature of the output branching: > There is no restriction on where those branches go. They may loop back > to self. >=20 > Now lets take the four examples listed.o > +---------------+ +-----------------+ > | | | | > | | | OUT +--> > ... OUT +--> ... | > | | | EXCEPTIONOUT +--> > | | | | > +---------------+ +-----------------+ >=20 > a. One output b. Two distinct outputs >=20 > I see no difference between the two. One has two branches and=20 > the otehr > has one. >=20 > +---------------+ +-----------------+ > | | | EXCEPTIONOUT +--> > | OUT:1 +--> | | > ... OUT:2 +--> ... OUT:1 +--> > | ... +... | OUT:2 +--> > | OUT:n +--> | ... +... > +---------------+ | OUT:n +--> > +-----------------+ >=20 > c. One output group d. One output and one output group >=20 > Again i see no difference of these from the general model above. > The contendig issue seems to be that in c. and d. you can keep adding > these > output branches to the LFB instance. Sure, depending on the capability > of the LFB thats just fine; you should be able to edit its > runtime properties and add more branches. >=20 > I have to run to work, hopefully that gets my concerns across. >=20 > cheers, > jamal >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 27 22:17:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17372 for ; Tue, 27 Apr 2004 22:17:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIedV-0000mW-4u for forces-archive@ietf.org; Tue, 27 Apr 2004 22:17:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIecd-0000fT-00 for forces-archive@ietf.org; Tue, 27 Apr 2004 22:16:28 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BIeby-0000YW-00 for forces-archive@IETF.ORG; Tue, 27 Apr 2004 22:15:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00D89123@cherry.ease.lsoft.com>; Tue, 27 Apr 2004 22:15:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 13858085 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 27 Apr 2004 22:15:47 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 Apr 2004 22:13:01 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042719162259:14206 ; Tue, 27 Apr 2004 19:16:22 -0700 References: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 07:16:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 07:16:25 PM, Serialize complete at 04/27/2004 07:16:25 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083118377.1033.84.camel@jzny.localdomain> Date: Tue, 27 Apr 2004 22:12:57 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Revised LFB input/output text Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Tue, 2004-04-27 at 18:40, Yang, Lily L wrote: > Jamal -- > The key difference I see in your view and the view described in the model > document is regarding the output branching -- everything else you said seem > in sync with the model we have in mind. The input has several choices of which what i have in minds fits in one of three posibilities. So that part is fine. > In your description: > > 5) There may be multiple output paths from an LFB > > 6) Processing results which may consult state decide on the output > > edge/branch to take. > > 7) metadata may be encoded as a result of #6 above in order to > > influence nexthop LFB processing (as described in #4 above) > I understand that the branching is driven by the "metadata". There are several "branchings" a) to the "processing" within an LFB b) to the output post processing. #a maybe be influenced by metadata and existing state. Seems like you refer to #b which is not driven by metadata. > But we need > to explicitly model that behavior somewhere in this graph. > And the picture you drew shows that one output from LFB can branch into > several different LFB for next step of processing. It is not clear to me > where/how the "metadata driven branching" is modeled. I think you are refering to #b above - i dont see any metadata driven branching either. > That kind of branching is prohibited explicitly in our current model with > a good reason: > "A single LFB output can be connected to only one LFB input. This is > required to make the packet flow through the LFB topology > unambiguous." > An output can only connect to one input. The diagram may have been misleading. The text desription in #5 is very explicit. I think we may have deviated a little because of that confusion; so dont bother responding to above text. Let me redraw the representation to be: +--------------+ +------------------+ | LFB X +---+ | | +--------------+ +--------------+ | | +----->| LFB A | | | | +--------------+ .... ... . ... .. .| | +-->|input LFB | . .. . ... ... .^ | +->------> Default/exception | | | +--------------+ | | |. . | LFB Z |---+ | | +--------------+ +------------------+----------> LFB D > A simple way to model that behavior would be inserting a "redirector" LFB > between the output branch and the multiple next step LFBs. The "redirector" > LFB has one input and multiple output, and the only processing > it does is to send packets to different output according to the metadata. No, let me stop here since the assumption for everything you said is based on a single output that may go to multiple LFBs. >Another thing you said which I don't quite agree is that you don't see >any difference in example a) and b). If the LFB to be modeled tend to >process the packets and sort them into two different categories -- then >we should model them explicitly within the LFB and the multiple >outputs enable just that -- the semantic difference between the two >outputs. > >Granted, just because we provide all these mechanisms/alternatives, it >doesn't mean every LFB designer has to use it for every LFB. I tend to >think of what FE model provides as what C language provides. You can >choose to use array, struct to make your program more readable, more >elegant. But you can also choose ignore all that, just use simple >scalar variables to do everything -- it is probably still doable, >theoretically. But there are times when you realize it definetely makes >big difference if you use the right constructs. My main problem is i see no need for output groups at all. Every edge of "output group" is infact a branch decision - by definition there could be one or multiple branches. Of course you can give them labels and a namespace to make them look pretty in a diagram; however, grouping them has semantical connotations. To be precise, the outputs can be described as in a simplistic C like description (since you brought that up;->): a) can be described as: result = process_packet(); send(output0); b) result = process_packet(); if (result = xxx) send(output0); else /* default */ send(EXCEPTIONOUT); You can apply the same concept to c) and d). Theres no difference between any of a), b), c) or d). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 28 11:25:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21327 for ; Wed, 28 Apr 2004 11:25:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqwP-0006nq-Hn for forces-archive@ietf.org; Wed, 28 Apr 2004 11:25:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqvR-0006h5-00 for forces-archive@ietf.org; Wed, 28 Apr 2004 11:24:42 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BIqub-0006ai-00 for forces-archive@IETF.ORG; Wed, 28 Apr 2004 11:23:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00D8A469@cherry.ease.lsoft.com>; Wed, 28 Apr 2004 11:23:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 13962581 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 28 Apr 2004 11:23:49 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 Apr 2004 09:51:59 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6879190 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 28 Apr 2004 09:51:58 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040428094440.02467df8@localhost> Date: Wed, 28 Apr 2004 09:51:41 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083118377.1033.84.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 It is true that output groups are not "necessary". We could simply declare that an LFB simply has outputs numbered 1 to n. (Where for some LFBs n is fixed and for some LFBs n is variable.) There are two related motivations that have prompted us to create the concept of output group. Firstly, there are semantics associated with the way LFBs will use certain output ports. As such, it is helpful to identify the semantics. This means that in the description one can say that certain packets go to the "error" port. It also means that the CE can understand explicitly that it is connecting following LFBs to the error output vs a normal output. (In particular, this makes it easier for a human being to follow what the CE has done when she needs to diagnose what is going wrong.) These means that we want some named outputs. Secondly, when ports have related semantics it is helpful to have the ability to group them together. So a branching classifier can have a table which gives the index of the output to be used for a packet which matches a specific table entry. This leads to wanting ports with specific semantics and indexing. I hope that clarifies things a bit further. Yours, Joel M. Halpern At 10:12 PM 4/27/2004 -0400, Jamal Hadi Salim wrote: >My main problem is i see no need for output groups at all. Every edge of >"output group" is infact a branch decision - by definition there could >be one or multiple branches. Of course you can give them labels and a >namespace to make them look pretty in a diagram; however, grouping them >has semantical connotations. To be precise, the outputs can be described >as in a simplistic C like description (since you brought that up;->): > >a) can be described as: > >result = process_packet(); >send(output0); > >b) >result = process_packet(); >if (result = xxx) > send(output0); >else /* default */ > send(EXCEPTIONOUT); > > >You can apply the same concept to c) and d). Theres no difference >between any of a), b), c) or d). From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 28 23:38:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14384 for ; Wed, 28 Apr 2004 23:38:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ2Nx-0004So-2i for forces-archive@ietf.org; Wed, 28 Apr 2004 23:38:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2Mz-0004MR-00 for forces-archive@ietf.org; Wed, 28 Apr 2004 23:37:54 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2MC-0004Fr-00 for forces-archive@IETF.ORG; Wed, 28 Apr 2004 23:37:04 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00D8B546@cherry.ease.lsoft.com>; Wed, 28 Apr 2004 23:37:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14037172 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 28 Apr 2004 23:37:05 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 Apr 2004 23:36:27 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042820401857:186 ; Wed, 28 Apr 2004 20:40:18 -0700 References: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 08:40:19 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 08:40:21 PM, Serialize complete at 04/28/2004 08:40:21 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083209760.1050.52.camel@jzny.localdomain> Date: Wed, 28 Apr 2004 23:36:23 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Revised LFB input/output text Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040428094440.02467df8@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-04-28 at 09:51, Joel M. Halpern wrote: > It is true that output groups are not "necessary". > We could simply declare that an LFB simply has outputs numbered 1 to > n. (Where for some LFBs n is fixed and for some LFBs n is variable.) > > There are two related motivations that have prompted us to create the > concept of output group. > > Firstly, there are semantics associated with the way LFBs will use certain > output ports. As such, it is helpful to identify the semantics. This > means that in the description one can say that certain packets go to the > "error" port. It also means that the CE can understand explicitly that it > is connecting following LFBs to the error output vs a normal output. (In > particular, this makes it easier for a human being to follow what the CE > has done when she needs to diagnose what is going wrong.) The semantics from the way you describe them imply an embedded decision process of some form to select 1 of n outputs. Why is for example an error port so speacial? > These means that we want some named outputs. No problem with this. Tagging a certain port/branch as an error port is fine. > Secondly, when ports have related semantics it is helpful to have the > ability to group them together. why? Explaining this may help me sync. > So a branching classifier can have a table > which gives the index of the output to be used for a packet which matches a > specific table entry. This leads to wanting ports with specific semantics > and indexing. sure, but why would grouping help in any of this? > I hope that clarifies things a bit further. Knowing you, I am sure you are saying something clever that i am still not getting. HEres my take: 1) there are 0..n-1 possible outputs. This part is fine to be modeled as a group or array etc. It is also fine to associate names to those branches. The CE can decide at policy install time the decision making process on selecting the output branching. At runtime when possible one can also redefine the decision making process as well (adding or removing to from those possible outputs) 2) A decision part selects from 0..n-1 outputs to use ( i was trying to demonstrate that in pseudo code). Somehow this is encompassed in your description but only implictly. its #2 that iam running into issues with. In my looking at this picture from perspective of #2 i see #1 as 0..n-1 branches and dont see the motivation to have a group of branches. Again From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 28 23:44:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14811 for ; Wed, 28 Apr 2004 23:44:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ2Te-0005Ag-5J for forces-archive@ietf.org; Wed, 28 Apr 2004 23:44:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2Sj-00054e-00 for forces-archive@ietf.org; Wed, 28 Apr 2004 23:43:50 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2SG-0004yS-00 for forces-archive@IETF.ORG; Wed, 28 Apr 2004 23:43:20 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00D8B47B@cherry.ease.lsoft.com>; Wed, 28 Apr 2004 23:43:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14037673 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 28 Apr 2004 23:43:21 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 Apr 2004 23:42:09 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042820460169:193 ; Wed, 28 Apr 2004 20:46:01 -0700 References: <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <1083209760.1050.52.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 08:46:02 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 08:46:02 PM, Serialize complete at 04/28/2004 08:46:02 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083210126.1057.54.camel@jzny.localdomain> Date: Wed, 28 Apr 2004 23:42:07 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083209760.1050.52.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit BTW, Just so we are on the same page, the box i drew is a representation of an _instance_ of a LFB class. cheers, jamal On Wed, 2004-04-28 at 23:36, Jamal Hadi Salim wrote: > On Wed, 2004-04-28 at 09:51, Joel M. Halpern wrote: > > It is true that output groups are not "necessary". > > We could simply declare that an LFB simply has outputs numbered 1 to > > n. (Where for some LFBs n is fixed and for some LFBs n is variable.) > > > > There are two related motivations that have prompted us to create the > > concept of output group. > > > > Firstly, there are semantics associated with the way LFBs will use certain > > output ports. As such, it is helpful to identify the semantics. This > > means that in the description one can say that certain packets go to the > > "error" port. It also means that the CE can understand explicitly that it > > is connecting following LFBs to the error output vs a normal output. (In > > particular, this makes it easier for a human being to follow what the CE > > has done when she needs to diagnose what is going wrong.) > > The semantics from the way you describe them imply an embedded decision > process of some form to select 1 of n outputs. > Why is for example an error port so speacial? > > > These means that we want some named outputs. > > No problem with this. Tagging a certain port/branch as an error port is > fine. > > > Secondly, when ports have related semantics it is helpful to have the > > ability to group them together. > > why? Explaining this may help me sync. > > > So a branching classifier can have a table > > which gives the index of the output to be used for a packet which matches a > > specific table entry. This leads to wanting ports with specific semantics > > and indexing. > > sure, but why would grouping help in any of this? > > > I hope that clarifies things a bit further. > > Knowing you, I am sure you are saying something clever that i am still > not getting. HEres my take: > 1) there are 0..n-1 possible outputs. This part is fine to be modeled as > a group or array etc. It is also fine to associate names to those > branches. > The CE can decide at policy install time the decision making process > on selecting the output branching. At runtime when possible one can also > redefine the decision making process as well (adding or removing to from > those possible outputs) > 2) A decision part selects from 0..n-1 outputs to use ( i was trying to > demonstrate that in pseudo code). Somehow this is encompassed in your > description but only implictly. > > its #2 that iam running into issues with. In my looking at this picture > from perspective of #2 i see #1 as 0..n-1 branches and dont see the > motivation to have a group of branches. > > Again From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 29 10:28:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05247 for ; Thu, 29 Apr 2004 10:28:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCWI-0006Dc-TS for forces-archive@ietf.org; Thu, 29 Apr 2004 10:28:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCVJ-0005zI-00 for forces-archive@ietf.org; Thu, 29 Apr 2004 10:27:10 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BJCUK-0005hr-00 for forces-archive@IETF.ORG; Thu, 29 Apr 2004 10:26:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00D8C102@cherry.ease.lsoft.com>; Thu, 29 Apr 2004 10:26:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14123561 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 29 Apr 2004 10:26:10 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 Apr 2004 10:25:04 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6882733 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 29 Apr 2004 10:25:03 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040429100859.0222b6f8@localhost> Date: Thu, 29 Apr 2004 10:24:39 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083209760.1050.52.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Let me try to separate issues a little. One aspect is how does an LFB class definition describe the decision process (and parameters) used by an instance of that class to choose which output to send a packet to. The current approach envisioned (and probably not well described) in the model is taht the processing logic of an LFB Class is described informally. We are not expecting to define a pseudo-language for LFB processing logic. Rather we expect to use english descriptions. This does imply that the writers of CEs will need to build into the CE understanding of the relevant behavior of any LFB class it needs to work with. We are not providing any noticeable assistance for the CE understanding teh semantics of an LFB class. The textual description for an LFB class might say that the LFB validates the IP header, and anything that fails the check is sent to the error output singleton. Anything that passes the check has its meta-data examined and branches by examining a dispatch table indexed by the "service-class" meta-data element and giving the output index in the normal-output port group. Another LFB class definition might indicate that the LFB examines only the MAC protocol, and sends packets to the IS-IS, IPv4, IPv6, MPLS, and error outputs. (You might prefer a table driven LFB, but that is a different debate.) For this later class, the CE gives orders connecting the different outputs to the kinds of processing specific to that packet type. There is much less of an issue with consistency between the logic of the LFB instance, the connectivity created by the LFB, and the programming provided by the human & policy machinery. What we are trying to do is make it easier for the CE, FE, and human to understand the semantics of the interfaces to the LFB class. If we only allowed one variable-count port group in an LFB class definition, then the naming of Singleton ports and output groups could be looked at as simply an aliasing for the 1..n outputs of the LFB class. Such aliasing makes understanding easier. When we started down taht path, we noticed that in some circumstances more than one semantic classes might have a variable number of outputs. For that case, named port groups is actually noticeably more flexible than just aliasing the ports. To elaborate, if I have OG1 which can have up to 10 outputs and OG2 which can have up to 10 outputs, but the LFB can have only 10 total outputs, there is no way to assign OG1 and OG2 as aliases against ports 1-10 such that I can grow OG1 or OG2 as I need to as services are added to the instance. With the port groups I can easily describe what I am doing. I can achieve the same affect by just explicitly managing the direct outputs, and keeping track of how I am using each 1 (a careful examination of the configuration tables would probably allow a human to determine which ports are being treated with semantic 1 and which ports are being treated with semantic 2.) Now, I will readily admit that most cases I can craft right now that use two variable output groups can easily be done with two cascaded branchers. And may be better done that way. But I am reluctant to declare that there can only be one variable sized output group just because I have insufficient foresight. Yours, Joel At 11:36 PM 4/28/2004 -0400, Jamal Hadi Salim wrote: >1) there are 0..n-1 possible outputs. This part is fine to be modeled as >a group or array etc. It is also fine to associate names to those >branches. >The CE can decide at policy install time the decision making process >on selecting the output branching. At runtime when possible one can also >redefine the decision making process as well (adding or removing to from >those possible outputs) >2) A decision part selects from 0..n-1 outputs to use ( i was trying to >demonstrate that in pseudo code). Somehow this is encompassed in your >description but only implictly. > >its #2 that iam running into issues with. In my looking at this picture >from perspective of #2 i see #1 as 0..n-1 branches and dont see the >motivation to have a group of branches. From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 29 12:18:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11756 for ; Thu, 29 Apr 2004 12:18:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEEz-0004q1-Gc for forces-archive@ietf.org; Thu, 29 Apr 2004 12:18:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEE5-0004Zc-00 for forces-archive@ietf.org; Thu, 29 Apr 2004 12:17:30 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BJEDT-0004JN-00 for forces-archive@IETF.ORG; Thu, 29 Apr 2004 12:16:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00D8C4AB@cherry.ease.lsoft.com>; Thu, 29 Apr 2004 12:16:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14133710 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 29 Apr 2004 12:16:48 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 128.9.160.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 Apr 2004 20:05:58 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3T058U05041; Wed, 28 Apr 2004 17:05:08 -0700 (PDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Message-ID: <200404290005.i3T058U05041@boreas.isi.edu> Date: Wed, 28 Apr 2004 17:05:08 -0700 Reply-To: rfc-editor@RFC-EDITOR.ORG Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: rfc-editor@RFC-EDITOR.ORG Subject: RFC 3746 on Forwarding and Control Element Separation (ForCES) Framework To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3746 Title: Forwarding and Control Element Separation (ForCES) Framework Author(s): L. Yang, R. Dantu, T. Anderson, R. Gopal Status: Informational Date: April 2004 Mailbox: lily.l.yang@intel.com, rdantu@unt.edu, todd.a.anderson@intel.com, ram.gopal@nokia.com Pages: 40 Characters: 98660 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-forces-framework-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3746.txt This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040428170313.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3746 --OtherAccess Content-Type: Message/External-body; name="rfc3746.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040428170313.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 29 12:37:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12716 for ; Thu, 29 Apr 2004 12:37:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEXJ-0002Yl-W6 for forces-archive@ietf.org; Thu, 29 Apr 2004 12:37:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEWB-0001z0-00 for forces-archive@ietf.org; Thu, 29 Apr 2004 12:36:12 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BJEUz-0001bL-00 for forces-archive@IETF.ORG; Thu, 29 Apr 2004 12:34:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00D8C50F@cherry.ease.lsoft.com>; Thu, 29 Apr 2004 12:35:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14136154 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 29 Apr 2004 12:35:00 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 Apr 2004 12:31:56 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3TGW01Y006577 for ; Thu, 29 Apr 2004 16:32:00 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3TGVmKs002554 for ; Thu, 29 Apr 2004 16:32:03 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042909314720203 for ; Thu, 29 Apr 2004 09:31:47 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 09:31:47 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ForCES Framework issued as RFC 3746 Thread-Index: AcQuB3arVvf2aY0gR7Ov5MnEJeCDzg== X-OriginalArrivalTime: 29 Apr 2004 16:31:47.0466 (UTC) FILETIME=[7750F6A0:01C42E07] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Thu, 29 Apr 2004 09:31:46 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Framework issued as RFC 3746 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, The ForCES Framework has just issued as RFC 3746. Congratulations all and a big thank you to the ForCES framework authors for all the=20 hard work! -David