Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-12

[Ballot discuss]
I'm holding a Discuss to ensure that questions from IANA are answered. Mail on this topic came from Pearl Liang on Feb 8th and March 18th. Let me know if I missed a response; I may not have been on all lists at the time.

I would also suggest that the document use RFC 5226 terms for the private ranges. For instance, in Section 10.2:

  Metadata ID 0x80000000-0xFFFFFFFF
      Metadata IDs in this range are reserved for vendor private
      extensions and are the responsibility of individuals.

=>

  Metadata ID 0x80000000-0xFFFFFFFF
      Metadata IDs in this range are reserved for vendor private
      extensions and are the responsibility of individuals, i.e.,
      used according to the Private Use [RFC5226] policy.

[Ballot comment]
A Gen-ART review by Meral included one small editorial suggestion (below). Have the authors considered this change?

---

Section 11, the following sentence can be written :
"The ForCES protocol document [RFC5810] includes a comprehensive set of security mechanisms and which implementations are required to support, and which deployments can use to meet these needs.  "
Suggestion:
"The ForCES protocol document [RFC5810] includes a comprehensive set of security mechanisms that implementations are required to support to meet these needs."

[Ballot comment]

Apologies in advance, I'm very very ignorant of ForCES.
(That'll be clear as you read below;-)

- I think the security considerations section should
reference 5811 which I think specifies the MTI security
for forces. That specifies SCTP/IPsec, which made me
wonder how much use that actually gets.

- Is it possible to brick an FE by loading in a instances
that create an infinite loop? If so, that'd be worth a
mention in the security considerations maybe.

- I was surprised not to see mention of WiFi/802.11 here
and wondered if/how wireless ports might differ from wired
and whether or not that ought be represented somewhere in
this document. (Is ForCES just not for such devices?
That's ok if so, I just wondered and haven't read other
ForCES RFcs.)

- p6, "LFB Class and LFB Instance - LFBs are categorized
by LFB Classes.  An LFB Instance represents an LFB Class
(or Type) existence.  There may be multiple instances of
the same LFB Class (or Type) in an FE.  An LFB Class is
represented by an LFB Class ID, and an LFB Instance is
represented by an LFB Instance ID.  As a result, an LFB
Class ID associated with an LFB Instance ID uniquely
specifies an LFB existence." Huh? What's an "existence"?
I found this definition unclear fwiw but I think I get
that each instance has a class and that the instance and
class identifiers together provide a way to uniquely
identify an instance.

- p6, definition of "ForCES Protocol" says: "This document
defines the specifications for this ForCES protocol." but
then at the end of the definitions you say "The LFB Class
Library is defined by this document." which seems odd. Is
the first one a cut'n'paste error?

- s3, intro, 1st para, 1st sentence: 5810 isn't the
framework, 3746 is or else something has the wrong
title;-)

- 4.4: I didn't check the schema, I do hope that someone's
checked it vs. their code etc.

- section 5, last para before 5.1: does this mean that
nodes (FEs) MUST ignore XML elements/attributes that they
don't understand/expect? If so, saying it that way would
be better IMO.

- 5.1.1.1 introduces the term "singleton" without defining
it, and its not clear to me what it does mean. (That might
be because that term has a specific meaning in DTNs e.g.
as defined in rfc 4838, that's different but not entirely
different and that that confuses me:-)

- 5.1.2.1 last para: "This document does not go into the
details of how this is implemented; the reader may refer
to some relevant references." That doesn't seem very
helpful.

- 5.1.2.2, typo: "The default value for is 'false'"
(occurs more than once)

- 5.1.2.2, 3rd last para: how does the FE generate an
error for something it doesn't implement if the rule is
that FE's ignore unknown XML elements? I'm confused now
between this and the text just before the start of 5.1.

- 5.3.3, shouldn't you add references for ECMP and RPF?
(Good to do even if you're not fully doing the work here,
since you do talk about 'em a bit.)

- 5.3.3, I'm not clear how e.g. you'd need another LFB to
support ECMP but yet but yet 5.3.3.1 says "An ECMP flag is
defined in the LPM table to enable the LFB to support
ECMP."

- 5.4.1, says "Note that all metadata visible to the LFB
need to be global and IANA controlled." I'm not sure what
you mean by that.

[Ballot comment]
A nit:

Section 3.1., paragraph 11:

>        *  Fragments datagrams when necessary to fit into the MTU of the
>            next network.

  It is not the 'next network' but rather the MTU of the next link/interface,
  as the NE instance cannot know the MTU restrictions of the whole
  network path.

IANA has reviewed draft-ietf-forces-lfb-lib-10 and has the following comments:

We have questions about the IANA actions requested in this document.

We understand that, upon approval of this document, there are four
actions which we must complete.

First in the Logical Functional Block (LFB) Class Names and Class Identifiers subregistry of the Forwarding and Control Element Separation (ForCES) registry located at:

www.iana.org/assignments/forces/forces.xml

fifteen (15) new entries are to be added to the registry as follows:

+-----------+---------------+------------------------+--------------+
| LFB Class | LFB Class Name|    Description        |  Reference  |
| Identifier|              |                        |              |
+-----------+---------------+------------------------+--------------+
|    3    |  EtherPHYCop  | Define an Ethernet port|[ RFC-to-be ] |
|          |              | abstracted at physical |              |
|          |              | layer.                | Section 5.1.1|
|          |              |                        |              |
|    4    |  EtherMACIn  | Define an Ethernet    |[ RFC-to-be ] |
|          |              | input port at MAC data | Section 5.1.2|
|          |              | link layer.            |              |
|          |              |                        |              |
|    5    |EtherClassifier| Define the process to  |[ RFC-to-be ] |
|          |              | decapsulate Ethernet  | Section 5.1.3|
|          |              | packets and classify  |              |
|          |              | the packets.          |              |
|          |              |                        |              |
|    6    |  EtherEncap  | Define the process to  |[ RFC-to-be ] |
|          |              | encapsulate IP packets | Section 5.1.4|
|          |              | to Ethernet packets.  |              |
|          |              |                        |              |
|    7    |  EtherMACOut  | Define an Ethernet    |[ RFC-to-be ] |
|          |              | output port at MAC    | Section 5.1.5|
|          |              | data link layer.      |              |
|          |              |                        |              |
|    8    | IPv4Validator | Perform IPv4 packets  |[ RFC-to-be ] |
|          |              | validation.            | Section 5.2.1|
|          |              |                        |              |
|    9    | IPv6Validator | Perform IPv6 packets  |[ RFC-to-be ] |
|          |              | validation.            | Section 5.2.2|
|          |              |                        |              |
|    10    | IPv4UcastLPM  | Perform IPv4 Longest  |[ RFC-to-be ] |
|          |              | Prefix Match Lookup.  | Section 5.3.1|
|          |              |                        |              |
|    11    | IPv6UcastLPM  | Perform IPv6 Longest  |[ RFC-to-be ] |
|          |              | Prefix Match Lookup.  | Section 5.3.3|
|          |              |                        |              |
|    12    |  IPv4NextHop  | Define the process of  |[ RFC-to-be ] |
|          |              | selecting Ipv4 next hop| Section 5.3.2|
|          |              | action.                |              |
|          |              |                        |              |
|    13    |  IPv6NextHop  | Define the process of  |[ RFC-to-be ] |
|          |              | selecting Ipv6 next hop| Section 5.3.4|
|          |              | action.                |              |
|          |              |                        |              |
|    14    |  RedirectIn  | Define the process for |[ RFC-to-be ] |
|          |              | CE to inject data      | Section 5.4.1|
|          |              | packets into FE LFB    |              |
|          |              | topology.              |              |
|          |              |                        |              |
|    15    |  RedirectOut  | Define the process for |[ RFC-to-be ] |
|          |              | LFBs in FE to deliver  | Section 5.4.2|
|          |              | data packets to CE.    |              |
|          |              |                        |              |
|    16    | BasicMetadata | Dispatch input packets |[ RFC-to-be ] |
|          |    Dispatch  | to a group output      | Section 5.5.1|
|          |              | according to a metadata|              |
|          |              |                        |              |
|    17    |    Generic    | Define a preliminary  |[ RFC-to-be ] |
|          |  Scheduler  | generic scheduling    | Section 5.5.2|
|          |              | process.              |              |
+-----------+---------------+------------------------+--------------+

Second, a new registry called the "Metadata ID Namespace" is to be created in the Forwarding and Control Element Separation (ForCES) registry located at:

www.iana.org/assignments/forces/forces.xml

Metadata ID values are 32 bits long. 

The rules for registration in this subregistry are:

For Metadata ID values 0x00000000-0x7FFFFFFF maintenance is done through Specification Required as defined by RFC 5226.

The authors request that for Metadata ID values 0x80000000-0xFFFFFFFF: "Metadata IDs in this range are reserved for vendor private extensions and are the responsibility of individuals."

Question - Do the authors mean that this range is maintained via Private Use as defined in RFC 5226?

There are initial registrations in this subregistry as follows:

+--------------+-------------------------+--------------------------+
|  Value      |          Name          |        Reference        |
+--------------+-------------------------+--------------------------+
|  0x00000001  |      PHYPortID        |      [ RFC-to-be ]      |
|  0x00000002  |        SrcMAC          |      [ RFC-to-be ]      |
|  0x00000003  |        DstMAC          |      [ RFC-to-be ]      |
|  0x00000004  |      LogicalPortID    |      [ RFC-to-be ]      |
|  0x00000005  |        EtherType      |      [ RFC-to-be ]      |
|  0x00000006  |          VlanID        |      [ RFC-to-be ]      |
|  0x00000007  |      VlanPriority      |      [ RFC-to-be ]      |
|  0x00000008  |      NextHopIPv4Addr  |      [ RFC-to-be ]      |
|  0x00000009  |      NextHopIPv6Addr  |      [ RFC-to-be ]      |
|  0x0000000A  |      HopSelector      |      [ RFC-to-be ]      |
|  0x0000000B  |      ExceptionID      |      [ RFC-to-be ]      |
|  0x0000000C  |      ValidateErrorID    |      [ RFC-to-be ]      |
|  0x0000000D  |        L3PortID        |      [ RFC-to-be ]      |
|  0x0000000E  |      RedirectIndex    |      [ RFC-to-be ]      |
|  0x0000000F  |    MediaEncapInfoIndex  |      [ RFC-to-be ]      |
+--------------+-------------------------+--------------------------+


Third, a new registry called the "Exception ID Namespace" is to be created in the Forwarding and Control Element Separation (ForCES) registry located at:

www.iana.org/assignments/forces/forces.xml

Exception ID values are 32 bits long. 

The rules for registration in this subregistry are:

For Exception ID values 0x00000000-0x7FFFFFFF maintenance is done through Specification Required as defined by RFC 5226.

The authors request that for Exception ID values 0x80000000-0xFFFFFFFF: "Exception IDs in this range are reserved for vendor private extensions and are the responsibility of individuals."

Question - Do the authors mean that this range is maintained via Private Use as defined in RFC 5226?

There are initial registrations in this subregistry as follows:

+--------------+---------------------------------+------------------+
|  Value      |          Name                  |  Reference      |
+--------------+---------------------------------+------------------+
|  0x00000000  |  AnyUnrecognizedExceptionCase  |  [ RFC-to-be ]  |
|  0x00000001  |        ClassifyNoMatching      |  [ RFC-to-be ]  |
|  0x00000002  |  MediaEncapInfoIndexInvalid    |  [ RFC-to-be ]  |
|  0x00000003  |      EncapTableLookupFailed    |  [ RFC-to-be ]  |
|  0x00000004  |            BadTTL              |  [ RFC-to-be ]  |
|  0x00000005  |    IPv4HeaderLengthMismatch    |  [ RFC-to-be ]  |
|  0x00000006  |        RouterAlertOptions      |  [ RFC-to-be ]  |
|  0x00000007  |        IPv6HopLimitZero        |  [ RFC-to-be ]  |
|  0x00000008  |      IPv6NextHeaderHBH        |  [ RFC-to-be ]  |
|  0x00000009  |      SrcAddressExecption        |  [ RFC-to-be ]  |
|  0x0000000A  |      DstAddressExecption        |  [ RFC-to-be ]  |
|  0x0000000B  |        LPMLookupFailed          |  [ RFC-to-be ]  |
|  0x0000000C  |      HopSelectorInvalid        |  [ RFC-to-be ]  |
|  0x0000000D  |      NextHopLookupFailed        |  [ RFC-to-be ]  |
|  0x0000000E  |          FragRequired          |  [ RFC-to-be ]  |
|  0x0000000F  |      MetadataNoMatching        |  [ RFC-to-be ]  |
+--------------+---------------------------------+------------------+

Fourth, a new registry called the "Validate Error ID Namespace" is to be created in the Forwarding and Control Element Separation (ForCES) registry located at:

www.iana.org/assignments/forces/forces.xml

Validate Error ID values are 32 bits long. 

The rules for registration in this subregistry are:

For Validate Error ID values 0x00000000-0x7FFFFFFF maintenance is done
through Specification Required as defined by RFC 5226.

The authors request that for Validate Error ID values 0x80000000-0xFFFFFFFF: "Validate Error IDs in this range are reserved for vendor private extensions and are the responsibility of individuals."

Question - Do the authors mean that this range is maintained via Private Use as defined in RFC 5226?

There are initial registrations in this subregistry as follows:

+--------------+---------------------------------+------------------+
|  Value      |          Name                  |  Reference    |
+--------------+---------------------------------+------------------+
|  0x00000000  | AnyUnrecognizedValidateErrorCase| [ RFC-to-be ]    |
|  0x00000001  |        InvalidIPv4PacketSize    | [ RFC-to-be ]    |
|  0x00000002  |          NotIPv4Packet        | [ RFC-to-be ]    |
|  0x00000003  |    InvalidIPv4HeaderLengthSize  | [ RFC-to-be ]    |
|  0x00000004  |    InvalidIPv4LengthFieldSize  | [ RFC-to-be ]    |
|  0x00000005  |        InvalidIPv4Checksum    | [ RFC-to-be ]    |
|  0x00000006  |      InvalidIPv4SrcAddr        | [ RFC-to-be ]    |
|  0x00000007  |      InvalidIPv4DstAddr        | [ RFC-to-be ]    |
|  0x00000008  |      InvalidIPv6PakcetSize      | [ RFC-to-be ]    |
|  0x00000009  |          NotIPv6Packet          | [ RFC-to-be ]    |
|  0x0000000A  |      InvalidIPv6SrcAddr        | [ RFC-to-be ]    |
|  0x0000000B  |      InvalidIPv6DstAddr        | [ RFC-to-be ]    |
+--------------+---------------------------------+------------------+

We understand that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (ForCES Logical Function Block (LFB) Library) to Proposed Standard


The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'ForCES Logical Function Block (LFB) Library'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document defines basic classes of Logical Function Blocks (LFBs)
  used in the Forwarding and Control Element Separation (ForCES).  The
  basic LFB classes are defined according to ForCES FE model and ForCES
  protocol specifications, and are scoped to meet requirements of
  typical router functions and considered as the basic LFB library for
  ForCES.  The library includes the descriptions of the LFBs and the
  XML definitions.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review
===

Hi,

I have done my usual AD review of your I-D prior to sending it forward
for IETF last call. Apologies that it has taken me so long to process:
it is not the shortest document, and I was not as familiar with ForCES
as I might have been.

The purpose of my review is to sort out any issues that might come up
during IETF last call or IESG evaluation to make sure that the use of
those steps is as efficient as possible, and to ensure that I can
fully support the document as it goes through those stages.

Set out below are a number of questions, nits, and requests for
additional text. It looks to me that they will add up to the need for
a new revision, so I will put the document into "Revised I-D Needed"
state in the datatracker, and wait for the new revision to be posted.

Of course, *all* my points are open for discussion and it may be that
each can be addressed using email rather than changing the document.

Thanks for your work.

Adrian

===

Please pick up the minor nits and unresolved comments referenced in the
Shepherd Write-up.

---

I didn't find Figure 1 very helpful at this stage of the document with
zero description. I know you want to defer detailed discussion until
Section 7, but some really brief description of what the figure contains
would have helped: what are the boxes? where are the inputs? where are
the outputs? what is the story with IPv6 and multicast? explain there
are multiple interfaces, etc., etc.

---

I am really uneasy about you using an enumeration for LANSpeedType.
There are three concerns:
- this is not future-proofed without needing to revise the LFB
- this does not cover all existing Ethernet interface types currently
  available (e.g., wifi, etc., etc.)
- you cannot slot new values into the list and keep them well-ordered

You might claim to get away with this by stating (as you do in 3.1 and
5.1) that this library only supports copper media. But I don't see how
you will extend to other media. Will you introduce a whole new structure
in parallel for other media? Not to mention other L2 encapsulations.

None of this seems very forward-looking.

---

I see that IEEEMAC is defined as a 6 byte thing which works for MAC-48
and EUI-48. How is EUI-64 handled?

---

A bit odd to define the SchdDisciplineType atomic data type given that
it only has one possible setting defined.

---

Looking at the stats I see they use simple integer types.  Indeed you
don't have atomic types for counters. But I can't find anywhere in the
document that talks about what happens when counters wrap or how to
record a discontinuity.

---

In general, I found the  text in Section 4 rather hard to
work with. It is either cryptic and terse, or in need of review.

For example...

           
                LFBOutputSelectIndex
               
                  Index for a packet to select a port instance in
                  EtherClassifier LFB group output port to link to a
                  downstream LFB. Possible downstream LFBs are
                  IPv4Validator, IPv6Validator, RedirectOut, etc.
               

...does not parse!

Then...

               
                  ClassifyNoMatching
                 
                    There is no matching of tables in EtherClassifier
                    LFB.
                 

...and...

               
                    MetadataNoMatching
                   
                      There is no matching when looking up the metadata
                      dispatch table in BasicMetadataDispatch LFB.
                   

...No matching what?

---

In 4.4 in IPv4PrefixTableInfo, what is this all about...

           
                Reserved
                Reserved for future use
                uchar
           

Actually, I see several similar (e.g. in VlanInputTableEntryType)

If this is an extensible format (I thought it was) why do you have
reserved fields?

---

5.2.2.1

  This LFB performs IPv6 validation according to [RFC2460].

Defining IPv6 validation by RFC 2460 seems limited. What about the RFCs
that update 2460?

I note that in 5.2.1.2 for IPv4 validation you are able to point at a
ForCES RFC (5812). Why isn't there an equivalent RFC for IPv6?

---

Section 5.3 discusses the actual and potential implementation
architectures and implies that some are more suited to this library than
others. That bothers me: this whole project is supposed to be about
abstraction and the abstraction is supposed to suit any (reasonable)
implementation model since it is the functions of forwarding that are
described, not the components of an implementation.

So I think the section should not make (what I think are dubious)
statements about "typical" and "usual" implementations. If it is
necessary to mention implementations (which I don't think it is) you
should do so in a light way and just note that this library is agnostic
to the implementation model and can be applied across all
implementations with recognition that the functional elements described
in the LFBs might be realised in a different way in an implementation,
but that the functions performed will be identical.

---

Section 5.3.1

  This LFB also provides facilities to support users to implement
  equal-cost multi-path routing (ECMP) or reverse path forwarding
  (RPF).  However, this LFB itself does not provide ECMP or RPF.  To
  fully implement ECMP or RPF, additional specific LFBs, like a
  specific ECMP LFB or an RPF LFB, will have to be defined. This work
  may be done in the future version of the document.

I guess it won't :-)

---

Section 5.3.1.2

Isn't the order of entries in IPv4PrefixTable supposed to have an
implicit meaning? Maybe this has to be discussed in this section or
maybe it belongs with the definition of IPv4PrefixTableType.

Obviously the same issue applies to IPv6.

---

Section 5.5.1.1

  The second output is a singleton output port known as "ExceptionOut",
  which will output packets for which the data processing failed, along
  with an additional ExceptionID metadata to indicate what caused the
  exception.  Currently defined exception types include:

  o  There is no matching when looking up the metadata dispatch table.

The implication here is that there are other members of ExceptionID that
are also currently valid.  Is that the case? if not, perhaps you could
change the wording slightly.

(This is a problem repeated throughout Section 5, but it only struck me
when I got this far :-)

But it does bring up the usual concern with a common set of return codes
that are shared across a number of functions. In this case, you use
ExceptionID for output from a number of different LFBs, but some values
are only appropriate for some LFBs. How does an implementer understand
which values are appropriate for which LFBs? Is the text in Section 5
supposed to be normative in this respect? I would have expected to find
some help in the XML (maybe in the descriptive text or maybe in the
normative definition), but all we have is a pointer to the atomic type
itself: for example,

           
                ExceptionOut
               
                  The output port outputs packets for which the data
                  processing failed, along with an additional
                  ExceptionID metadata to indicate what caused the
                  exception.
               
               
                 
                      Arbitrary
                 
                 
                      ExceptionID
                 
               
           

---

Section 7.2

  The EtherEncap LFB, as described earlier, receives packets that need
  Ethernet L2 encapsulating.

I felt that a direct pointer would be more helpful than "as described
earlier".

This led me on to thinking that the use case would be more interesting
if it also showed how the CE actually put information into the
EncapTable and how EtherEncap uses that table.

---

Sections 10.2, 10.3, 10.4

  Why have you chosen "Specification Required" instead of something that
  requires the work to be done inside the IETF? (I know that the
  designated expert will help to keep control of this, but I would like
  to understand why you feel that this should be opened up in this way.

---

Sections 10.2, 10.3, 10.4

  Metadata ID 0x80000000-0xFFFFFFFF
      Metadata IDs in this range are reserved for vendor private
      extensions and are the responsibility of individuals.

...etc.

You should express this in RFC 5226 language (i.e., "Private Use").

Generally I don't like "Private Use" definitions in the routing area,
but I suppose we can argue that this is really an management/application
layer protocol and pass on that. but I am a little disappointed that
there is very little discussion of the use of private values. 5.4.1.1 and
5.4.2.1 make mention, but only to suggest looking in the IANA
Considerations section for more details (which do not exist). I would
also have thought that there are Security implications of the use of
"Private Use" values.

More text, please.