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