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

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Jul 2003 21:33:21 -0400

Yes (as one would expect I would say.)
Joel M. Halpern

At 04:22 PM 7/25/2003 -0700, you wrote:
>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: "Yang, Lily L" <[email-masked]>
Date: Sun, 27 Jul 2003 15:12:35 -0700

Hi, Weiming --
If I understand it correctly, you suggest that we allow a mechanism to define coarse grain FE blocks by combining fine grain FE blocks together. I agree that is useful and should be allowed in the model. What do other people think?
 
Lily

-----Original Message-----
From: Weiming Wang [mailto:[email-masked]]
Sent: Saturday, July 26, 2003 1:05 PM
To: [email-masked]
Subject: Re: WG question: Accept draft-yang-forces-model-02.txt as WG doc?

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.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 28 Jul 2003 12:03:28 -0700

I agree that this draft should be accepted as a WG draft.

Hormuzd
-----Original Message-----
From: Crouch, Alan [mailto:[email-masked]] 
Sent: Saturday, July 26, 2003 10:26 PM
To: [email-masked]
Subject: Re: [FORCES] WG question: Accept draft-yang-forces-model-02.txt
as WG doc?

Yes - I recommend that the FE Functional Model draft below is ready to
become a ForCES working group document, as outlined in the WG charter.

Alan

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 6:33 PM
> Subject: Re: [FORCES] WG question: Accept
draft-yang-forces-model-02.txt
> as WG doc?

---

From: Alistair Munro <[email-masked]>
Date: Tue, 29 Jul 2003 10:30:08 +0100

Hi All,

Resend - I forgot that my e-mail address had changed.

>
> I recommend adopting the draft as a WG document. The discussions about
> latencies, ordering, MUXes, number of inputs/outputs to graph nodes, etc.
> are too operational and implementation specific in my opinion, and risk
> overloading the model with too much semantics.
>
> The NPF has been grappling with this problem for some time, without
> solving it either. My take on where the NPF is right now is that, out
> there, there are FEs which are modeled using a graph abstraction of
> nodes, representing functions, connected (possibly acyclicly, possibly as
> a multigraph - think this is the right term) by edges whose semantics
> represent some implementer/integrator defined relationship. The purpose
> of the NPF model is to give a naming (typing) and instance addressing
> framework (necessary) plus a means of linking nodes (optional). That's as
> far as a model should go.
>
> As an example of *using* the model, the NPF DiffServ group has proposed a
> DiffServ FE structure, which is, in my opinion, a set of working
> assumptions about a set of typical DiffServ blocks and how they could be
> related, not a model or, even, architecture in itself.
>

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eagroup.com

---

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 29 Jul 2003 10:42:05 -0700

Alex -- 
To answer your questions:
1) FE block is contained in the FE, not the whole FE itself. FE block
topology is intra-FE topology.
2) You are right. The connection to/from CE should be drawn differently
as the input/output because they are distinctly different -- for one,
each block does have its own logical input and output while it does not
really have each own connection to CE -- all blocks inside an FE share
one ForCES protocol entity with one logical channel to/from CE. Drawing
it with another block might also help to clarify.

Thanks,
Lily

-----Original Message-----
From: Alex Audu [mailto:[email-masked]] 
Sent: Monday, July 28, 2003 8:56 AM
To: [email-masked]
Subject: Re: WG question: Accept draft-yang-forces-model-02.txt as WG
doc?

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: Tue, 29 Jul 2003 14:10:11 -0400

"Putzolu, David" wrote in a private email:
>
> Thanks for your comments on the model.  As a significant
> participant in this work, do you think you could weigh
> in explicitly on the list as to whether you feel the
> model doc is ready or not to be a WG doc an thus the basis
> for further discussion and changes?  I hesitate to interpret
> your posts as a vote for/against it - too much risk of
> misinterpretation.

  I believe that the model document is ready to be a working group
document.

  There have been a few comments on the list about details relating to
the FE Blocks, which I will include in the next revision of the
document.  The issues raised have been ones of detail, so I believe that
the consensus is that the main substance of the document is OK.

  The text in the document about the FE Blocks then reflects the
consensus of the group, even when that consensus is "no final decision
has been made", or "we are unsure as to how to solve this problem."  By
explicitely writing down such statements in the document, we obtain a
solid foundation for focussing further discussion.

  Alan DeKok.

---

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 30 Jul 2003 05:26:18 -0700

Hi, Weiming -

This PkfID seems to me like one meta-data. But before I can fully
understand what it is, I have one question regarding the diagram you
draw below - if the same PkfID is used for both the connections to
Queue1 and Queue2, how do you know which packet goes to which queue?

Thanks,

Lily

-----Original Message-----
From: Weiming Wang [mailto:[email-masked]] 
Sent: Saturday, July 26, 2003 1:05 PM
To: [email-masked]
Subject: Re: WG question: Accept draft-yang-forces-model-02.txt as WG
doc?

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.