Subject: IESG feedback on the requirements draft

From: Patrick Droz <[email-masked]>
Date: Wed, 28 May 2003 13:58:52 +0200

I was asked by the AD to give a summary of the discussion
triggered by IESG feedback and how it influenced the
requirements draft. I invite people to comment on these
issues especially if they do not like the way the
requirements draft has been amended.

Regards,
Patrick

 > > 1) it is not clear how different efforts (most of which
 > > referenced in the
 > > draft) interconnect: e.g. midcom (similar protocol between hosts,
 > > typically), gsmp, ccamp.

we basically found agreement that multiple of these can
be present.

 > > 2) I find the justification a bit questionable:
 > >
 > >                       A standard set of mechanisms for connecting
 > >    these components provides increased scalability and allows the
 > >    control and forwarding planes to evolve independently, thus
 > >    promoting faster innovation.
 > >
 > > .. it seems to me that in practice, such independent evolution and
 > > innovations typically require changes in both elements: I
 > > doubt one can
 > > create such a generic architecture which would accommodate anything
 > > happening to the other in the future.

it is not expected that the functionality of FEs will develop
faster.

 > > 3) the applicability of ForCES seems to be unclear, for example:
 > >
 > >    Addressable Entity (AE) - A physical device that is directly
 > >    addressable given some interconnect technology.  For
 > example, on IP
 > >    networks, it is a device to which we can communicate using an IP
 > >    address; and on a switch fabric, it is a device to which we can
 > >    communicate using a switch fabric port number.
 > >
 > > .. the latter would seem to indicate some support for non-IP
 > > devices too,
 > > or should this use some rewording to clarify which kind of
 > > switch fabric was the question was all about?

clarifying text added

 > > 4) I haven't delved into ForCES, but the last two sentences
 > > look a bit
 > > scary:
 > >
 > >    Forwarding Element (FE) - A logical entity that implements the
 > >    ForCES protocol.  FEs use the underlying hardware to provide per-
 > >    packet processing and handling as directed by a CE via the ForCES
 > >    protocol.  FEs may use PFE partitions, whole PFEs, or
 > >    multiple PFEs.
 > >
 > > .. this seems to imply that CE's instruct logical FE's to
 > > perform some
 > > tasks, while there exists some protocol between FE->PFE.
 > >
 > > - what is used between FE and PFE's?
 > > - are there interoperability reqs between FE / PFE's (can
 > > they be from
 > > different vendor)?
 > > - is this useful at all?  Seems like very dangerous to me --
 > > because might
 > > require an additional abstraction layer at FE's -- which
 > > might make the
 > > CE-FE control even more useless (too generic) and less powerful.

clarifying text added.

 > > 5) Is the partitioning concept really useful?  Could you list some
 > > applicability scenarios?

yes, it is considered useful.

 > > 6) Is it possible to have multiple CE's manage one FE?
 > This probably
 > > would have tradeoffs and drawbacks, but is integral when you
 > > consider the applicability of the protocol (ie. is it a
 > network management
 > > protocol or control-dataplane protocol).

yes you can have multiple CE's controlling an FE. Text
added to the draft.

 > > 7) Is it necessary/useful to keep the ForCES protocol
 > > open-ended even now?
 > > I fail to see valid reasons for multiple protocols..:
 > >
 > >    ForCES Post-Association Phase Protocol - [...]
 > >                      This protocol could be a single protocol or
 > >    could consist of multiple protocols working together.

it is clear in the charter to consider other protocols.

 > > 8) Again, the ForCES model seems quite open-ended:
 > >
 > >    FE Manager - A logical entity that operates in the
 > pre-association
 > >    phase and is responsible for determining to which CE(s)
 > a FE should
 > >    communicate.  This process is called CE discovery and may involve
 > >    the FE manager learning the capabilities of available CEs.  A FE
 > >    manager may use anything from a static configuration to a pre-
 > >    association phase protocol (see below) to determine
 > which CE(s) to
 > >    use.  Being a logical entity, a FE manager might be physically
 > >    combined with any of the other logical entities mentioned in this
 > >    section.
 > >
 > > ... I fail to see the usability of FE's discovering CE(s).  Being a
 > > master-slave association where CE's are masters, I would
 > > think it would be
 > > natural to assume CE's are the masters and thus _they_
 > discover their
 > > slave FE's.

more clarifying text added to the draft

 > > 9) In the snippet above and some others: it seems to be
 > > typical in the
 > > requirements to overload the terminology with rather long
 > > architectural
 > > descriptions.  This has both good and bad sides, but in any
 > > case it should
 > > be considered whether some other way to achieve the big
 > > picture would be
 > > more usable.
 > >
 > > Also, there are some terms in the terminology which are not
 > > used in the
 > > document.  If this is also meant as a terminology document,
 > > this might be
 > > ok, but otherwise keeping to the minimum might be useful.

all unused terminology has been removed from the draft

 > > 10) The list of FE functions below is extensive:
 > >
 > >    Some functions that FEs could perform include layer 3 forwarding,
 > >    metering, shaping, firewall, NAT, encapsulation (e.g.,
 > tunneling),
 > >    decapsulation, encryption, accounting, etc.  Nearly all
 > > combinations
 > >    of these functions may be present in practical FEs.
 > >
 > > .. but in reality, gives little hope, as the list is far from
 > > complete,
 > > and completely evolving.  It seems apparent that if one tries to
 > > standardize all the possible functions, with *a lot* of
 > > abstractization,
 > > this is a source of a LOT of work, and work that's never
 > going to end.
 > >
 > > .. so, it might be useful to consider the scope: deal with
 > > the most basic form of forwarding, and that only, for now.

this created some controversy. First the DT was asked to
come up with relevant functionality then was asked to reduce.
The consensus seems to be that the list is what the driving
people like to see.

 > > 11) The last sentence here implies a possible disconnect in the
 > > architecture:
 > >
 > >    1) CEs and FEs MUST be able to connect by a variety of
 > interconnect
 > >    technologies.  Examples of interconnect technologies used
 > >    in current
 > >    architectures include Ethernet,bus backplanes, and ATM (cell)
 > >    fabrics.  FEs MAY be connected to each other via a different
 > >    technology than that used for CE/FE communication.
 > >
 > > ==> Is it intended to connect FE's to CE or provide a FE-FE
 > > protocol?
 > > Having some interconnection and/or protocol between FE's
 > > seems useful in a
 > > sense, but also potentially out of scope of this architecture.

more clarifying text was added to the draft

 > > 12) This sounds very challenging:
 > >
 > >    The variety of FE functionality that the ForCES
 > architecture allows
 > >    poses a potential problem for CEs.  In order for a CE to
 > > effectively
 > >    control a FE, the CE must understand how the FE
 > processes packets.
 > >    We therefore REQUIRE that a FE model be created that can
 > > express the
 > >    logical packet processing capabilities of a FE.
 > >
 > > .. I'd say that most functionalities differ *a lot* from
 > > vendor to vendor.
 > > Are you really, really sure that you should (or can) express
 > > all of these
 > > in completely independent way *AND* that subsequent use if
 > > it's understood
 > > would be *effective*.  Also see other s ubsections here, like 6.2.

The DT is the opinion that it will be possible to agreed
an a a model incorporating the behavior of standards
compliant routers.

 > > 13) Another architectural problem..:
 > >
 > > 6.3. Ordering of Logical Functions
 > >    The model MUST be capable of describing the order in which these
 > >    logical functions are applied in a FE. The ordering of logical
 > >    functions is important in many cases.  For example, a
 > NAT function
 > >    may change a packet's source or destination IP address.
 > Any number
 > >    of other logical functions (e.g., layer 3 forwarding,
 > > ingress/egress
 > >    firewall, shaping, accounting) may make use of the source or
 > >    destination IP address when making decisions.  The CE
 > needs to know
 > >    whether to configure these logical functions with the pre-NAT or
 > >    post-NAT IP address. [...]
 > >
 > > .. so are we talking about N! possible orderings (with N
 > > possible logical
 > > functions).  Seems like a horror ("pre-nat post-qos-meter
 > > pre-qos-classification pre-forward-do-something foo bar boo
 > > baf"-state).

no it is not N!. There is a subset of potential alternatives.
There is enough flexibility required to be future proof.

 > > 14) I'm having difficulties parsing the actual requirements in:
 > >
 > >    8)Off-loaded Functions
 > >
 > > .. do you require that basically any piece of code CE wants
 > > to offload to
 > > FE's must be supported as long it's expressed as a finite
 > > state machine..
 > > or what?  That that code is to be executed on all (or a
 > > specified portion
 > > of)  the packets?

here there was a misunderstanding. It was never intended to
off-load code pieces. The idea was to do things like TCP off
loading in case the FE has such capability built into it.

 > > 16) on the use of reliable protocols:
 > >
 > >    4)Multihop
 > >    When the CEs and FEs are separated beyond a single hop,
 > the ForCES
 > >    protocol will make use of an existing RFC2914 compliant
 > L4 protocol
 > >    with adequate reliability, security and congestion control (e.g.
 > >    TCP, SCTP) for transport purposes.
 > >
 > > ==> I fail to see the added value of a separate protocol for
 > > singlehop links; there, the latency is low and reliable protocols
 > > should be quite usable.

this was one of the most heavily discussed issues. The DT
updated the text in the draft.

 > > 17) security considerations should be properly written out, a
 > > blind referral insufficient:
 > >
 > > 9. Security Considerations
 > >
 > >    See architecture requirement #5 and protocol requirement #2.

More text on security was added to the draft.

---

From: Alex Audu <[email-masked]>
Date: Wed, 28 May 2003 13:42:54 -0500

Hello Patrick,

I'll like to comment briefly on the following which I excerpted from the
original e-mail.

===

===
[Alex] Multiple CEs can control an FE to provide CE redundant services
to the FE, but only one CE (the active one) can be in control at a time.
In an Active/Standby situation, the active CE is in control. In a Load-shared

situation, the time of control is shared amongst the CEs.

Regards,
Alex.