Subject: Fwd: Re: draft-ietf-forces-requirements-08.txt

From: Alex Zinin <[email-masked]>
Date: Mon, 7 Apr 2003 10:56:19 -0700

David, Patrick-

 Below are the comments from Pekka (an OPS-DIR member), consider
 them backed up by Randy as part of IESG review.

 Thanks.

-- 
Alex
http://psg.com/~zinin/

Comments on forces-reqs-08.  In summary, I'd like to express a very grave
concern of trying to address every possible problem, a path that seems
doomed to failure.  Note a list of dozen different forwarding 
functionalities that still fail to capture all of them -- and the 
associated complexity of handling all the different nuances and orderings 
of these functions.

Seems way, WAY too complex to make interoperable and useful.  I wonder how
far we have to go with this effort to see it as a dead-end.  Or
alternatively, some other architectural/approach revamp might be able to
salvage some of the mechanisms (e.g. concentrate on certain core tasks
only, but then again, one might question how useful the mechanism is).

Substantial:
------------

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.

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.

Again in:

 By allowing the control and
   forwarding planes to evolve independently, different types of FEs
   can be developed - some general purpose and others more specialized.

.. this seems a bit questionable: different types of FEs can already be
developed, and have been developed for a long time now.  What you're
aiming for is mixing and matching a CE one or more FE's with a standard
protocol with different characteristics and possibly different vendors.

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?

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.

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

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).

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.

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.

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.

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.

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.

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 subsections here, like 6.2.

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).
Same again in:

   The FE model MUST be capable of expressing complex sets of filtering
   functions.  The model MUST be able to express the existence of these
   functions at arbitrary points in the sequence of a FE's packet
   processing functions.

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?

15) I don't disagree that security must be supported (btw. nit: s/make 
private/encrypt/), but..:

   2)Support for Secure Communication
   a) FE configuration will contain information critical to the
      functioning of a network (e.g. IP Forwarding Tables). As such, it
      MUST be possible to ensure the authenticity and integrity of
      ForCES protocol messages.
   b) FE configuration information may also contain information derived
      from business relationships (e.g. service level agreements).
      Therefore, it MUST be possible to secure (make private) ForCES
      protocol messages.

.. I'm not sure how applicable this is in in most/some scenarios.  For 
example, if the interconnect between CE and FE's is a shared/dedicated 
bus, e.g. an ethernet link, I'm not sure how applicable these are.   
Basically if the control messages traverse over the Internet, they should 
be securable.  I'm not sure how one considers the possible deployment 
scenarios, but I don't think over-the-Internet case is too common 
(typically hinting at CE/FE located in a different NE).

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.

17) security considerations should be properly written out, a 
blind referral insufficient:

9. Security Considerations

   See architecture requirement #5 and protocol requirement #2.

Semi-editorial:
---------------

CEs may consist of PCE partitions or whole
   PCEs.

==> what about 'multiple PCEs' (compare to the text of FE's) ?

   Post-association Phase - The period of time during which a FE does
   know which CE is to control it and vice versa,

==> is "FE controlling CE" (through vice versa) ? I think not?

   2) FEs MUST support a minimal set of capabilities necessary for
   establishing network connectivity (e.g., interface discovery, port
   up/down functions).  Beyond this minimal set, the ForCES
   architecture MUST NOT restrict the types or numbers of capabilities
   that FEs may contain.

==> it is not unambiguous what the last sentence tries to say; does it 
take a stance that at least a minimum set of capability types must be 
supported, that ForCES must work in the presence of any possible set of 
capabilities, or what..

   9) Any proposed ForCES architectures MUST explain how that
   architecture supports all of the router functions as defined in
   [RFC1812].

==> this must be elaborated.  RFC1812 is a long RFC, and no proposal 
should be expected to go through all of these functions!  Clearly there 
are certain specific issues which need to be addressed here...

   10) In a ForCES NE, the FEs MUST be able to provide their topology
   information (topology by which the FEs in the NE are connected) to
   the CE(s).

==> the wording in ()'s doesn't really clarify much and should be 
rewritten; also, it's rather difficult to understand.  Same in the second 
version of this req.

   We therefore REQUIRE that a FE model be created that can express the

==> REQUIRE is not a proper RFC2119 keyword.

   2)Forwarding Functions
   The FE model MUST be capable of expressing the data that can be used
   by the forwarding function to make a forwarding decision. Support
   for IPv4 and IPv6 unicast and multicast forwarding functions MUST be
   provided by the model.

==> just as a comment, I fear multicast functions may be significantly 
more difficult to provide than unicast.

   The FE model SHOULD be extensible so that new, currently unknown  FE
   functionality can be expressed. The FE Model SHOULD NOT be extended
   to express standard/common functions in a proprietary manner. This
   would NOT be ForCES compliant.

==> NOT is not a proper RFC2119 keyword.

   5)Message Priority
   The ForCES protocol MUST provide a means to express the protocol
   message priorities.

==> should this be elaborated?  Ie., do you mean in the case protocol 
messages get queued and some messages are more important than others so 
they'll be able to overtake the queue?  (and not e.g. in TOS/traffic class 
context.)  Note that this may have quite interesting implications for 
multipart or sequenced commands, so prioritizing should be used with care.

   9)Packet Redirection/Mirroring
   a) The ForCES protocol MUST define a way to redirect packets from the
      FE to the CE and vice-versa. Packet redirection terminates any
      further processing of the redirected packet at the FE.

==> when redirected from CE to FE, the latter sentence does not parse 
properly.

Editorial:
----------

  Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF),
   its areas, and its working groups.  Note that other groups may
   also distribute working documents as Internet-Drafts. 
[...]

==> the boilerplate is not as-is.

  Conventions used in this document

==> I'd place this under a numbered section, at the introduction or 
something, but I'm not sure if there is a strict policy on that.
    
1. Abstract 

==> abstract must not be numbered, per ID-nits etc.

Khosravi, Anderson, et. al.   Expires July 2003               [Page 1]

==> this should be either "Khosravi, et al." or "Khosravi & Anderson"
(rfc-ed policy)

   8. References.....................................................13
 8.1. Normative References...........................................13
 8.2. Informative References.........................................13
   9. Security Considerations........................................13
   10. Authors' Addresses & Acknowledgments..........................14
   11. Editors' Contact Information..................................15

==> personally I'd like sec considerations before references (that's the
more typical way), but that's not a strict rule.

==> note that IPR & copyright statements are also missing, but those can 
be added later on too.  

   entities that cooperate to provide a given functionality (such as a
   routing or IP switching) and yet appear as a normal integrated

==> s/a routing/routing/

   For the purpose of illustration, let us consider the architecture of
   a router to illustrate the concept of separate control and

==> please try not to use the word "illustrate" twice.

   architectures include Ethernet,bus backplanes, and ATM (cell)

==> s/,bus/, bus/

   ForCES protocol elements from joining a NE.(For more protocol

==> s/(/ (/

requirement #1)
   details, refer to section 7 requirement# 2) 

==> choose the format how to refer to requirements and be consistent; I
prefer " #x" rather than "# x" but YMMV.

---

From: Ross Callon <[email-masked]>
Date: Wed, 09 Apr 2003 12:45:43 -0400

>protocol with different characteristics and possibly different vendors.

Are we concerned about the fact that the abbreviation CE refers to 
a Control Element in Forces, and also refers to Customer Edge
devices for L2 and L3 VPNs? This seems slightly worse than the
double use of LSP (Link State Packet, and Label Switched Path) 
since if FORCES is used at all then the context is likely to overlap:

Specifically, customer edge equipment which supports VPNs might 
use Forces technology. Thus the CE (customer edge device in VPN 
speak) consists of an NE (Network Element in Forces speak) which 
in turn is made up of a CE (Control Element) and an FE. 

How about Control Processor or CP?

Ross

---

From: Alex Zinin <[email-masked]>
Date: Fri, 2 May 2003 02:17:49 -0400

Ross,

  Just noticed I missed this e-mail.

  It seems that this is not a big deal. Just like we can be more
  specific and say ISIS LSP and MPLS LSP, we can also be more specific
  and say VPN CE, and ForCES CE, when necessary.

  One abbreviation overload that I kind of hate is IP used for
  "Intellectual Property"... unfortunately the IETF can't do anything
  about this ;)

-- 
Alex
http://www.psg.com/~zinin/