Subject: WG question: Accept draft-yang-forces-model-02.txt as WG doc?

From: "Putzolu, David" <[email-masked]>
Date: Fri, 25 Jul 2003 16:22:49 -0700

All,

At the 57th IETF meeting last week the authors of 
draft-yang-forces-model-02.txt asked that the draft 
be made a working group document.   The sense of
the room was that it should be.   I would like 
to see if there is consensus on the list on this.

Please indicate by August 1st whether you feel that 
the following draft is ready to become a ForCES
working group document:

http://www.ietf.org/internet-drafts/draft-yang-forces-model-02.txt

Note that becoming a working group document does
not finalize the document -  it means that the 
general direction and structure of the document 
is accepted as correct, and that the working 
group is willing to adopt is as the basis for 
further work.  If accepted as a WG document, it 
will remain a draft and will be subject to 
change based on feedback from the participants 
of the working group.

Thanks,
David

---

From: Weiming Wang <[email-masked]>
Date: Sun, 27 Jul 2003 04:04:32 +0800

Dear David, and Lily, Joel, Ram, and Alan,

As one in the mailing list, I favor this model draft as WG document. This surely can speed up WG work and make research more focusing.

I'm interested in the model work, so I have made some comments on this document as follows, hoping to be of some help to perfect the document:

1. In Figure 3(a) shown bellow, connections between blocks seem in an intersected way,

                          +--------------------- 
                          |                                             
         +-----------+    |     +-----------+                          
         |           |    v     |           |                                 
       ->| ingress   |--------->|classifier |----
         | ports     |          |           |---- 
         +-----------+          +-----------+    
                                                                                                    
I don't know if intersected connections may make topology representation more complex or not. Actually the figure can also be expressed as follows, 
         
                          +--------------------- 
                          |                                             
         +-----------+    |     +-----------+                          
         |           |    +---->|           |                                 
       ->| ingress   |--------->|classifier |----
         | ports     |          |           |---- 
         +-----------+          +-----------+    
                                                                                                    
Although a classifier may only have one input in the hardware viewpoint, this is practical, because FE models are abstraced models from the ForCES viewpoint. For the above changed figure, we only need to properly set classifier attributes then it can surely get the packets and know where they are from. 

If intersected connections may make things complicated, can it be stated in the document to aoid using it?

2. For FE block library, I recommend to add a quite functionarily universal block, which may be called a match block,show in following figure,
                          - - - - - - - - - - 
                         |   match block     
                                             | 
                         |  +------------+
                            |            |   |
                         |  |  rule base |
                            |            |   |
                         |  +------------+
                                   |         |
                         |         V 
                            +------------+   |
                         |  |            |------->
                   -------->|  matching  |------->
                         |  |            |....
                            |            |------->
                         |  +------------+   |
                          - - - - - - - - - -
This block is insidely composed of a rule base and a matching mechanism. It just does match according to the rule and outputs IP packets according to the rule's action to specific egresses. This block can be applied to classification, filtering, modifying, routing(forwarding),and even dropping. By using this block, ForCES protocol may be more uniformly and simpl made, since attributes for these block functions can maily be abstracted as rules, what we should do is to add rules, delete rules, etc. This doesn't mean that the real implementation of ForCES routers should also use such architecture. Again I think ForCES architecture are based on abstraction, the simple the abstraction the better, the bottom for abstraction is it can be implemented in hardware and codes. 

3. For the ways to model FE block topology, document have presented two approaches, Directed Graph Topological Approach and Encoded State Approach. The latter needs to use meta-data. These approaches are truely effective. Here I just want to introduce a way that I have been using in my experimental open programmable system and it has shown be practical and efficient in a real system(I have posted a message to ForCES list on this several days before). My approach is based on the openion that, in order to efficiently represent FE block topology, we not only need to define blocks explicitly from CE plane, we also need define the connections explicitly. This seems like superfluous words, but in fact it is not. Ways we now use are all trying to define connections implicitly(by meta-data or others). My approach is just to assign every connection a tag from CE plane, I call it a PacketFlowID(PkfID). Connection from one block egress to many other block ingresses(this may be used for broadcast or multicast)is only treated as one connection and assigned one PkfID, as following figure shows,

                                                                +---------+
                                                        +------>| Queue 1 | 
                                                        |       +---------+
                            +------------+   PkfID 1    |       +---------+
                            |            |--------------------->| Queue 2 |
                   -------->| classifier |------->              +---------+
                            |            |....
                            |            |------->
                            +------------+   
Where PkfID1 is assigned to connection that comes from a classifier output and goes individually to queue1 and queue2 blocks.
                          
PkfIDs are defined by CE at the time blocks are defined, and can be modified later during runtime. 

Note that connections defined by PkfIDs are still abstractive ones, we may have many connections which are in FE implementation plane only one physical connection, while PkfIDs are real to FE implementation. They act like global variables and implementation codes can use PkfIDs as index to fetch and put IP packets at correct places. From this point of view, PkfID acts also like a kind of "meta-data",but this "meta-data" doesn't make barriers, instead it make great benefits. Just by defining all the PkfIDs in an FE, the block topology is also defined. In my experimental system, till now I still haven't found any necessary to use specific modeling language(maybe later, I'l encounter difficulty, for my system is only based on single cpu based linux). I have also found PktIDs can be modified dynamically during runtime, so as to meet the requirements such as Diffserv and RSVP implementation. This may imply that whenever we need to change the IP packet walking way in FE, we in fact need to let CE know. So I guess for other functions that we now think may need "meta-data" to act, they may also able to be controlled by CE, so that "meta-data" in FE plane can be avoided. 

I have also considered if using of PkfIDs might disorder IP packets, but I find that when IP packets are need to be divided, there is no need to consider their orders at later blocks anymore. 

It also seems like that PkfIDs make me able to define some cookie(or applet) like codes at CE side, and they can be uploaded to FE, because PkfIDs make CE able to reach the real IP packet flows in FE. In this way, I guess if this can be used for CE to define brand new blocks or renew block algorithms in FE without FE manufacturers interfering, when manufacturers support the standardized code language. But the work is still in the way and result not assured.

4. For block manipulation on CE side, I think if it is needed for ForCES protocol to support block union and big new block defining dynamically, so as to simplify block configurations. For instance, a scheduler is usually associated with many queues, and for a FE or FEs in a NE, it's quite possible they have same scheduler structures and capabilities. If ForCES protocol is capable of defining a new block composed of these existing queues and scheduler, it will make configuration easier.

I'v written too much and may make you feel sleepy to read, so I will stop here. Anyway, I'm interested in your work and appreciate the document. If my comments are not relevant or with mistakes in it, please excuse me.

For fear the message might not display correctly because of the txt figure, I'v made a copy in Word in the attachment.

Best Regards,

Weiming Wang([email-masked] or [email-masked] )

---

From: Alex Audu <[email-masked]>
Date: Mon, 28 Jul 2003 10:56:14 -0500

Yes,  I think the draft should be accepted as working group document.

Some Comments:
1)  Section 4. FE Model Concepts: FE Block and FE Block Topology
     Please clarify if FE Block is contained in the FE or is the whole
FE itself.
     Also, does the "FE Block Topology" describe how the FE Blocks are
    connected inside the FE itself? In other words, is this intra- or
inter- FE
    topology?

2) Section 4.1 FE Blocks
  "An FE Block has inputs, outputs, and a connection to and from the CE
   as shown in Fig 2."   Are you refering to logical connections between

   CE and FE Blocks here?  Fig 2 could probably be more informative if
   it shows more than one FE block, together with the inter-block
connections.

Regards,
Alex

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Jul 2003 21:50:27 -0400

> Weiming Wang wrote:

> 2. For FE block library, I recommend to add a quite functionarily
> universal block, which may be called a match block,show in following
> figure,
...
> This block is insidely composed of a rule base and a matching
> mechanism.

  I don't see how this block is different than the classifier blocks
which already exists in the document.  The classifier block already has
internal state S, which encompases the "rule base" on which it makes its
decisions.

> It just does match according to the rule and outputs IP
> packets according to the rule's action to specific egresses. This
> block can be applied to classification, filtering, modifying,
> routing(forwarding),and even dropping.

  A block which is good for everything is good for nothing.

  The whole purpose of having multiple FE logical blocks is to clearly
define functionality.

  You appear to be asking that every block contain a "match" (or
classifier) block as part of its function.  Section 5.2.4, which
describes the classifier block specifically addresses this
misconception.

  When a block uses some of its internal configuration to decide how to
process input data, that block is NOT performing classification.  It is
simply making local decisions which are internal to that block, and
which are invisible outside of that block.  (Other than as edited
packets, etc.)

  The FE Classifier Block produces externally visible classification
results, which is its purpose.

> By using this block, ForCES
> protocol may be more uniformly and simpl made, since attributes for
> these block functions can maily be abstracted as rules, what we should
> do is to add rules, delete rules, etc.

  All you are saying here is that an FE block may have configuration
data, which a CE may update or edit.  We do not need an additional block
to describe this functionality.

> For fear the message might not display correctly because of the txt
> figure, I'v made a copy in Word in the attachment.

  You should put such a the document on a web page, in a form that other
people can read.  You have enough ideas that I suggest you write an
internet-draft which summarizes your work.

  Alan DeKok.

---

From: Jason Goldschmidt <[email-masked]>
Date: Tue, 29 Jul 2003 14:02:54 -0700

Yes - I recommend that this document becomes a working group document.
I believe it is taking the direction we want based on the ForCES working
group charter.

-Jason

--
Jason Goldschmidt
Sun Microsystems
Network Technology Office
[email-masked]