Subject: Feedback on ForCES Model v02

From: "Putzolu, David" <[email-masked]>
Date: Sun, 29 Feb 2004 16:46:59 -0800

[hat off]
Hi Lily et al.

Just finished reading the draft, below is my feedback.

Abstract: "Forwarding and Control Plane Separation" should be
          "Forwarding and Control *Element* Separation" - oops!

LFB metadata definition: It seems to me that implementations
might do more than encode metadata differently, they might
transport it differently (i.e. if a FE has a classification
processor and a traffic management processor, they might
use a shared memory region, or a streaming interface, or
some other interface to share metadata) or they might not
even have the metadata at all (i.e. if a NPU performs both
classification and traffic shaping, but directly associates
classification entries --> traffic shaping entries, it might
not even have the metadata in the actual fast path, but instead
use the metadata to setup the entries).  Maybe say:
   The FE model defines how such metadata is identified, 
   produced and consumed by the LFBs, but not how metadata 
   is encoded within an implementation. , "identified,
   produced and consumed by the LFBs, but not how per-packet 
   state is implemented within actual hardware"

Section 2.3 says:
   Definition of the various payloads of ForCES messages 
   (irrespective of the transport protocol ultimately selected) 
   cannot proceed in a systematic fashion until a formal 
   definition of the objects being configured and managed (the 
   FE and the LFBs within) is undertaken. 
This paragraph confused me a bit.  My belief is that one
*can* proceed in defining how LFBs are carried, identified,
and queried, without having to specify that a scheduler uses
a 64 bit unsigned int for representing minimum service rate
in bits per second.  This is analogous to how SNMP protocol
messages could be defined before all MIBs where defined.

Page 12 shows "internal control" in the figure. This is
confusing because the LFBs are still part of the ForCES
model of the actual FE implementation.  Perhaps say
"LFB manipulation" or "per-LFB interactions" here?

Page 13 replace "new LFB class can" with "new LFB classes can"

Section 3.2.1 Input group is confusing to me. If it
is only a way of identifying which LFB sourced a packet to
another FE, which not simply assert that LFBs are able to
determine which input connection # a packet arrived on?
Does input group offer anything more than this?  

Section 3.2.2 It isn't clear what the use of an output
group is. How would a FE or LFB use it?  LPM is the example 
given but doesn't make sense. If the LFB classifies a packet 
it will likely have a specific next LFB connection to send 
it on.  The alternative is to just say "send this packet on 
that output group" - but that makes for unpredictable /
unspecified behavior, which is (correctly) identified as 
undesirable.

Section 3.2.3 bottom of page 16: The underlying 
implementation may not be passing the packet at 
all.  E.g. an IP packet in an PPPoverATMAAL5 frame might 
actually consist of a  scattered bunch of pointers to 
pieces of the packet.  I'd suggest just shortening the 
2nd paragraph to say:
   "logically operates on, but this has no implications
   on how packets are stored or moved in the underlying
   implementation."

Section 3.2.3 bottom of page 17: Isn't it possible that
the underlying implementation not actually have metadata
in the fast path?  E.g. LFB 1 may associate metadata
with a packet:
  Address/mask: 10.0.0.0/255.0.0.0 --> metadata for next hop 1
and LFB 2 might associate that metadata with some action:
  packet w/metadata value 1 --> send out port 3
But the underlying implementation might not have any
metadata in the fast path, e.g.:
  Address/mask 10.0.0.0/255.0.0.0 --> send out port 3
Admittedly, there is software in between that stores
the metadata to then "cook" the data into the hardware
representation, but the point is the hardware may not
even have metadata.  So I'd suggest saying:
   "While it is important to define the metadata types
   passing between LFBs, it is not necessary to define
   the encoding mechanism used for LFBs for that
   metadata.  As with the ForCES model in general, no
   constraints are placed on underlying FE implementation
   of metadata as long as the FE behaves in a fashion
   that one would predict given a particular metadata 
   configuration.

In the next paragraph the term marking is overloaded.
Replace "marked" with "associated".

3.2.4.1 Forwarded is overloaded. Replace "forwarded 
by the LFB" with "passed on to the next LFB".

3.2.4.2 Why must there be at least one producer and
one consumer?  While I can see the need for a 
consumer to require an upstream producer (aside: it
would be better if each metadata consumer LFB, even 
non-optional ones, also specify what happens if the 
expected metadata is not present), there is no real 
need for each producer require a down graph consumer.

3.2.5 last para: Why are FEs disallowed from
supporting multiple versions of a particular
class? 

3.3.1 While hardware could influence topology, I think
it is more important that the data path be modeled in
a clear fashion.  If a single hardware classifier is 
used for two logically different classifications (e.g.
in IP in IP tunneling, one classification on the outer,
another on the inner DIP), that still would be better
represented as two separate LFB instances, unless one
specifically wants to reuse the same classification 
entries (e.g. an ACL where any access to certain ports
is to be blocked, whether on the inside or outside of
an IPinIP or IPsec tunnel mode connection).

3.3.1 Page 28/9 It says "One way to encode...". Not 
sure of the relevance of that. Is it the suggested
mechanism or the actual mechanism used in this document?
If so say so!

4.7 Re: editor's note: Should LFB class names 
be managed by IANA?

4.7.2 Re: Omitting the tag when a LFB has no input
ports - what about having a reserved "None" value?
Explicitly using a "none" statement tends to catch 
errors better than omission of the statement, 
which can happen by mistake and be a difficult bug
to catch.

4.7.3 Same comment

5.2.1.1 Make it mandatory that the element be present -
same reasoning as above, minimizes errors of omission.

5.2.2.4.1 Don't understand what namespace this is.
FE has no way of knowing what names the CE is assigning
to other FEs, so this must be something that the other
FEs communicate to the FE - should be a valid identifier
prior to CE<->FE connection, otherwise this becomes a
chicken & egg problem.  Each FE should have some unique
ID - maybe just use a MAC address perhaps that the FE owns.
Or is this what 5.2.2.4.4 is?

Section 6 general comment: This seems to be a very good
start on the following charter deliverable:

o A formal definition of the controlled objects in the
  functional model of a forwarding element. This
  includes IP forwarding, IntServ and DiffServ QoS. An
  existing specification language shall be used for
  this task.

I remember some discussion about splitting this off.
Do you think this should remain in the base model draft, 
or should it be split off as a separate doc/draft?

Section 6 general comment: Some ASCII art of each
of the LFBs showing inputs, outputs, etc., would be 
helpful.

6.1 Ports are tricky things. If a single LFB represents
both send and receive then all FE graphs will look like
cycles, which is rather confusing (and hard for a machine
to parse).  Of course, splitting ports also is confusing -
if one downed a receive LFB it would down the whole port,
affecting the transmit LFB as well. This isn't a new issue,
but the doc doesn't really explain how it will be addressed -
better to put a stake in the ground one way or the other.

6.2 Same comment applies

6.5 The bullet ". that is maintained at a downstream LFB"
  appears out of context, what is it referring to?

6.8 mentions a "Modifier LFB" that is not explained or
  mentioned elsewhere. 3.2.4 Mentions a Header Modifier LFB
  that is also not mentioned elsewhere - should both of these
  be "Packet Header Rewriter LFB"?

6.9 mentions packet length metadata (also 6.6 and 6.13) - 
  this is not really explained.  Since it is associated
  with all packets,  it seems like it need not really 
  be called out as metadata (perhaps treat it as implicit
  metadata that all LFBs know about, just as all LFBs can
  implicitly see the contents of the packet).  An alternative
  would be to say that every packet has special RO metadata
  always associated with it such as length.

6.17 Why are encapsulation & decapsulation together in
  one LFB?  Seems confusing - isn't encap & decap usually
  separate functions, performed on separate packet streams?

8.7 Need to address what happens to packets arriving at/
  transiting a FE during reconfiguration. Do they get 
  dropped on disconnected inter-LFB links? Start filling
  queues? Something else?

10. A model-specific security issue that should be mentioned
  is the risk of misconfiguring a LFB graph resulting in
  insecure behaviors.  Having software on a CE reconfigure 
  a LFB graph is a very easy way to shoot yourself in the foot.

That's all I had. Overall this document is looking very good,
once the remaining editor's notes are addressed and the WG has
had a chance to properly review it I think it will be ready to
proceed.

-David

> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of Yang, Lily L
> Sent: Tuesday, February 17, 2004 8:49 AM
> To: [email-masked]
> Subject: Re: [FORCES] I-D ACTION:draft-ietf-forces-model-02.txt
> 
> Hi, all --
> 
> The FE model design team just published v02 of the FE model document.
> The entire document has been edited throughout, but most notably some
> major progress has been reflected in this revision:
> 1) 3.2.4 "metadata" section is completely rewritten, with the metadata
> model that was published to this list by Zsolt a few weeks ago. We
> believe most comments we've received so far are addressed in this
> revision.
> 2) Section 4 "model and schema for LFB classes" is rewritten, with
> formal XML schema specified at the end of the section.
> 3) Section 5 "FE Attributes and Capabilities" now is 
> completed with also
> formal XML schema specification, that was also published to the list a
> few weeks ago by Joel.
> 4) The old section 6 in v01 was a place holder for LFB 
> topology and now
> gone because the content of LFB topology is merged into "FE attributes
> and Capabilities" in Section 5. The comments we received are also
> incorporated into this new revision.
> 5) Section 6 "LFB Class Library" (old section 7 in v01) is 
> also revised
> significantly with now 18 LFB classes that include the most commonly
> found functions for IP processing, forwarding and QoS.
> 6) Section 7 "satisfying the requirements" (old section 8 in v01) is
> also revised considerably.
> 
> With this revision, the major pieces that make up the FE model are now
> in place, with the exception of a few minor features here and there
> (e.g., class inheritance is not fully flushed out in the LFB 
> schema). We
> hope this revision would provide timely input into the protocol
> development. In the meantime, we hope the WG and especially 
> the protocol
> designers would take time to review and provide feedback on the FE
> model, so that we can refine it to the satisfaction of the WG in the
> next few months.
> 
> 
> Thank you all,
> 
> Lily
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, February 17, 2004 7:32 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-ietf-forces-model-02.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Forwarding and Control Element
> Separation Working Group of the IETF.
> 
>         Title           : ForCES Forwarding Element Functional Model
>         Author(s)       : L. Yang
>         Filename        : draft-ietf-forces-model-02.txt
>         Pages           : 101
>         Date            : 2004-2-17
> 
> This document defines the forwarding element (FE) model used in the
> Forwarding and Control Plane Separation (ForCES) protocol.  The
> model represents the capabilities, state and configuration of
> forwarding elements within the context of the ForCES protocol, so
> that control elements (CEs) can control the FEs accordingly.  More
> specifically, the model describes the logical functions that are
> present in an FE, what capabilities these functions support, and
> how these functions are or can be interconnected. This FE model is
> intended to satisfy the model requirements specified in the ForCES
> requirements draft [1].  A list of the basic logical functional
> blocks (LFBs) is also defined in the LFB class library to aid the
> effort in defining individual LFBs.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-forces-model-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-forces-model-02.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need 
> "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have 
> been split
>         up into multiple messages), so check your local 
> documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>