Subject: [forces] AD review of draft-ietf-forces-lfb-lib

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Dec 2012 00:09:03 -0000

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 <synopsis> text in Section 4 rather hard to
work with. It is either cryptic and terse, or in need of review.

For example...

             <component componentID="3">
                <name>LFBOutputSelectIndex</name>
                 <synopsis>
                   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.
                 </synopsis>

...does not parse!

Then...

                 <specialValue value="1">
                   <name>ClassifyNoMatching</name>
                   <synopsis>
                     There is no matching of tables in EtherClassifier
                     LFB.
                   </synopsis>

...and...

                 <specialValue value="15">
                    <name>MetadataNoMatching</name>
                    <synopsis>
                      There is no matching when looking up the metadata
                      dispatch table in BasicMetadataDispatch LFB.
                    </synopsis>

...No matching what?

---

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

             <component componentID="5">
                <name>Reserved</name>
                <synopsis>Reserved for future use</synopsis>
                <typeRef>uchar</typeRef>
             </component>

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,

             <outputPort group="false">
                <name>ExceptionOut</name>
                <synopsis>
                  The output port outputs packets for which the data
                  processing failed, along with an additional
                  ExceptionID metadata to indicate what caused the
                  exception.
                </synopsis>
                <product>
                   <frameProduced>
                      <ref>Arbitrary</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>ExceptionID</ref>
                   </metadataProduced>
                </product>
             </outputPort>

---

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.

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 11 Dec 2012 11:45:44 +0800

Hi Andrian, 

Thanks very much for the AD review. Authors will give response and finish version update asap.

thanks,
Weiming

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>

> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 14 Dec 2012 21:55:26 +0800

Hi Andian and all, 

I'm trying to give a first response  to AD's excellent reviews such that we start up resolving steps if the issues seem to need more discussions, and we try to give draft answers for consensus if the issues seem relatively clear to solve. Please just see texts inline with this purpose.

thanks,
Weiming

----- Original Message ----- 

> Please pick up the minor nits and unresolved comments referenced in the
Yes,we have carefully made a record on issues and relavent updates all the way till today.
> are multiple interfaces, etc., etc.
I think we need a discussion among authors and Jamal on how we try to deploy notations and ideas step by step  in the document. I'd very much like to hear Jamal's thought.

I think we need specially open a message to solve the issue. 

> None of this seems very forward-looking.

I think it is a relatively tough and important issue. The question may be summarized as: 1) do we have other better data structure than enumaration for describing a LAN speed ? 2) if no, do we have better enumaration method with more extesibility and flexibility? 

Authors pls contribute more thoughts, thanks.

> and EUI-48. How is EUI-64 handled?

Really good catch. 
Chuanhuang suggests then to use a union structure to include the EUI-64 as below. 

       <dataTypeDef>
          <name>IEEEMAC</name>
          <synopsis>IEEE MAC address</synopsis>
          <union>
             <component componentID="1">
               <name>MAC48 </name>
               <synopsis>MAC-48</synopsis>
               <typeRef> byte[6]</typeRef>
            </component>
            <component componentID="2">
               <name> EUI64</name>
               <synopsis>EUI-64</synopsis>
               <typeRef> byte[8]</typeRef>
            </component>
          </union>
       </dataTypeDef>

Any thoughts?

> it only has one possible setting defined.

We do had discussions when we designed this element. We just thought that although now it only sets Round Robin as the default and the only strategy, future extension might contain more types of scheduling strategies.

> document that talks about what happens when counters wrap or how to

Maybe defining a specific atomic counter with full definition on wrap and other properties is a very good treatment. Lets follow to discuss. Thanks.

> work with. It is either cryptic and terse, or in need of review.

Sure, we'l finish this work in the version. 

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

Pls see response from Jamal on this question. thanks.

> Defining IPv6 validation by RFC 2460 seems limited. What about the RFCs

Ok, Chuanhuang has checked RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564 for the relavence with this document and thinks RFC2460 ,RFC3513 and RFC6564 are related. 

> ForCES RFC (5812). Why isn't there an equivalent RFC for IPv6?

It was really resulted from a mistaken correction for previous version, which should be RFC(1812) as was in earlier version. We noticed this error also soon before. Really appreciate AD's careful work!

Moreover, Chuanhuang suggests to refer RFC1812 and RFC2644 for the IPV4 validation reference.

> but that the functions performed will be identical.

According to the discussion happend following the issue, we may need to re-phrase the text and make it isolated from implementations. If theses no more objection, I'l give updated text according to the thought soon. 

>   may be done in the future version of the document.

So, lets just remove the text of the last sentense ?

> (This is a problem repeated throughout Section 5, but it only struck me

At the beginning of design, we did believe it might have more than one case. We kept the format then. 
So, need change the wording. 

>                  ExceptionID metadata to indicate what caused the

Firstly, Section 5 is normative to LFB definitions rather than descriptively informative. 

Then, we thought a general exception definition should not result in abmiguity if implemeters obeys the text like in Section 5, i.e., for a specific LFB, Section 5 defines the exception cases and all other cases should not be translated in meaning. 

Hope authors give your understand of the issue. Thanks.

> I felt that a direct pointer would be more helpful than "as described
 
Modified to: "The EtherEncap LFB, as described in Section 5.1.4, receives packets that need Ethernet L2 encapsulating. " 

> EncapTable and how EtherEncap uses that table.

Ok, let us add some text at the end of Section 7.1 the use case for IPv4 forwarding to indicate how Encap LFB works inside. 

I hope to put the IANA related to a specific message and with the help of designated expert of IANA to solve the issues :) 

Thanks a lot.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Dec 2012 16:30:04 -0000

Hi Weiming...

[snip - reduced to issues needing further discussion]

> I think it is a relatively tough and important issue. The question may be
> summarized as: 1) do we have other better data structure than enumaration for
> describing a LAN speed ? 2) if no, do we have better enumaration method with
> more extesibility and flexibility?
> 

Have a look at ifSpeed in ifTable in RFC 1213

Also consider MplsBitRate in RFC 3811 and section 3.1.2 of RFC 3471.

> We do had discussions when we designed this element. We just thought that
> although now it only sets Round Robin as the default and the only strategy,
> future extension might contain more types of scheduling strategies.

OK. Maybe add a note?

> Maybe defining a specific atomic counter with full definition on wrap and
other
> properties is a very good treatment. Lets follow to discuss. Thanks.

Again. Suggest to look at what MIB and YANG modules do for wrapping counters,
fast counters (that need 64 bits), and discontinuities.

> Pls see response from Jamal on this question. thanks.

I meant to pick this up from Jamal's email, but forgot to come back to it.

Surely the rules in RFC 5810 take care of all packing and padding that is
necessary?

> So, lets just remove the text of the last sentense ?

Agree

Thanks,
Adrian

---

From: Joel <[email-masked]>
Date: Fri, 14 Dec 2012 11:43:52 -0500

With regard to attribute packing and reserved fields:

> Surely the rules in RFC 5810 take care of all packing and padding that is

In one sense, the answer is absolutely.  The rules in 5810 produce a 
clear format, and one that can be generated, shipped, received, and 
processed.  However, in laying out those rules we did not worry at all 
about the efficiency of such processing.
Jamal has pointed out that adding the reserved fields makes the 
processing significantly more efficient.

The question I am still of two minds on (but was willing to include in 
the spec), is whether that is a sufficient reason to add the noisy 
reserved fields to the definitions.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Dec 2012 21:02:49 -0000

Hi,

I guess I should go and read 5810, but why do that when I can simply ask you the
question? :-)

I'm confused by your answer, Joel.

My question was not whether 5810 is unambiguous, but about whether it takes care
of padding and packing.

That is, does 5810 pad single byte field up to multi-byte boundaries, or does
the next data field run on immediately after the single byte?

If the former, I don't see how this reserved field helps or is needed. If not
then I wonder if the problem isn't in the protocol encoding rather than in the
LFB (of course, fixing the protocol encoding now might be a bit tough if we want
to retain b/w compatibility!)

A

> -----Original Message-----
> From: Joel [mailto:[email-masked]]
> Sent: 14 December 2012 16:44
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [forces] AD review of draft-ietf-forces-lfb-lib
>

---

From: Joel Halpern <[email-masked]>
Date: Sat, 15 Dec 2012 23:29:34 +0000

5810 has no padding inside the fullsata.
Joel

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Adrian Farrel [[email-masked]]
Received: Saturday, 15 Dec 2012, 4:03pm
To: 'Joel' [[email-masked]]
CC: [email-masked] [[email-masked]]; [email-masked] [[email-masked]]
Subject: RE: [forces] AD review of draft-ietf-forces-lfb-lib

Hi,

A

---

From: Chuanhuang Li <[email-masked]>
Date: Sun, 16 Dec 2012 23:48:43 +0800

Hi, Adrian and All
 
>Also consider MplsBitRate in RFC 3811 and section 3.1.2 of RFC 3471.
Our definition may be somewhat different with MIB.  'AdminLinkSpeed' (read-write) and 
'OperLinkSpeed' (read-only) are defined in EtherPHYCop LFB.  So the configuring information 
'LAN_SPEED_AUTO' need to be included. We also add 'LAN_SPEED_NONE' to indicate 'Nothing 
is connected'.
As you know, we can't enumarate all of the possible ethernet speed type. We just list some 
typical values in ehternet with copper. 
Exactly, RFC 3471 also used the enumaration format. 
If we don't use enumaration method, and just use the real value to represent the speed type, 
we may need a way to speify the 'LAN_SPEED_AUTO' configuring mode.
Do Jamal and other authors have any thoughts?  Thanks!   

>fast counters (that need 64 bits), and discontinuities.
'uint64' is a built-in atomic type in RFC5812.  There are no range restrictions 
and special enumerated values in the statistic information type, so we havn't defined 
a new atomic type. 
Indeed there is no place to mention 'counter' in current lfb lib. If we think this is an 
implementation-specific problem, can we omit this definitiion?
Best regards!
Yours,
Chuanhuang

---

From: Joel <[email-masked]>
Date: Sun, 16 Dec 2012 12:01:30 -0500

I tend to prefer the enumeration.
The other choice is to us an integer (units of either megabits or 10s of 
megabits), and reserve 0 for not connected ad -1 for auto.  That seems 
even more awkward to me.

Yours,
Joel

On 12/16/2012 10:48 AM, Chuanhuang Li wrote:
>  >> ; summarized as: 1) do we have other better data structure than
> enumaration for

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 17 Dec 2012 11:09:29 +0800

In order to follow discussions and my document update work later accordingly, I'v renamed the message name and will follow it till resolved. For ease of collecting information, I'v also included a Jamal's response inside. 

thanks,
Weiming

-----Original Message----- 
From: Adrian Farrel [[email-masked]]
Received: Saturday, 15 Dec 2012, 4:03pm
To: 'Joel' [[email-masked]]
CC: [email-masked] [[email-masked]]; [email-masked] [[email-masked]]
Subject: RE: [forces] AD review of draft-ietf-forces-lfb-lib

Hi,

A

---------- Forwarded message ----------
From: Jamal Hadi Salim <[email-masked]>
Date: Tue, Dec 11, 2012 at 8:30 AM
Subject: Re: ID Tracker State Update Notice: <draft-ietf-forces-lfb-lib-09.txt>
To: IETF Secretariat <[email-masked]>
Cc: [email-masked], [email-masked]

Excellent review Adrian - and you made my job as shepherd easier by posting
on the list (I dont have to go chase the authors ;-> I see they picked
it up already).

On Mon, Dec 10, 2012 at 7:06 PM, IETF Secretariat
<[email-masked]> wrote:
>                 Reserved
>                 Reserved for future use
>                 uchar

I believe this was my suggestion based on implementation experience of
these LFBs.
The idea is to ensure that everything is 32 bit aligned. The protocol requires
that we have 32 bit alignment and those specific things you are looking
at labelled as "reserved" have "holes" which will end up being padded to
meet that requirement (and so they can be properly parsed at the receiver).
I suggested they be labelled as "reserved" to make them visible.

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 17 Dec 2012 11:15:15 +0800

Pls follow this message on discussion on this issue. 

Thanks,Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 17 Dec 2012 11:22:20 +0800

This is an editorial issue.  

thanks,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 17 Dec 2012 11:34:24 +0800

I hope to put the IANA related issue to a specific message and with the help of designated expert of IANA to solve the issue. Thanks a lot.

Weiming

---

From: Joel <[email-masked]>
Date: Sun, 16 Dec 2012 22:43:32 -0500

Adrian, I am not sure what your concern is about specification required 
and private use.
By the nature of ForCES, we expect folks to b making p their ow 
libraries.  We hope that they will use standard libraries for standard 
things, bu they will need proprietary or early ones.  (For example, on 
one project we did an LFB for SSID manipulation.) As such, they need to 
be able to create metadata IDs.
And, f someone does define one in a publicly readable spec, we would 
rather that other folks sue the same ID for the same semantics, rather 
than making up yet another metadatum.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 17 Dec 2012 07:06:46 -0500

On Sun, Dec 16, 2012 at 10:09 PM, Wang,Weiming <[email-masked]> wrote:
> In order to follow discussions and my document update work later accordingly, I'v renamed the >message name and will follow it till resolved.

Good idea Weiming (my email reader missed some of the threaded messages).

So this is more for Adrian (Sorry if this sounds too basic, but i think
context is important). Just illustrating on what Joel said:

To prefix: This is not a protocol or encoding issue rather an efficiency issue.

ForCES uses either TLVs or ILVs to encode the data. TLVs use 16 bit
T/L encoding whereas ILVs use 32 bit I/L where the I also serves as
part of the path.

Say I had a naive component definition of struct {id=1, uchar; id =2, uint32}

a) then such a struct can be encoded as a list of ILVs:
{ {I=1, L=1, V ={uchar}},  //requires 3B pad.
  {I=2, L=4, V ={uint32}}}  // no pad required
in such a case you will pad the V of the first ILV with 3 more bytes to
align to  32 bit. You will have spent a total of 16B to ship those 5B.

b) encode that as TLV. The cost of sending is dominated by the V of
the TLV and you are sending 5B padding for alignment is _at the end_
of that struct that costs you an extra 3B. So a total of 8B. More wire
byte efficient - so you just saved yourself half the bytes. Looks good
except implementation experience says it is less efficient from
accessing at a processing level on the FE. (evident on a small
32b-MIPS FE home router where access is in 4B and accessing
the uint32 would require two fetches; you could use "packing"
rules on ARM/MIPS and everything is accessed in 1B boundaries).
For our simple struct, the solution is to re-arrange those fields so
the 32 bit comes first in the component definition; in such a case you
still have the 3B pad at the end but now the 32b field is efficiently
accessible.

So the model definition of the struct plays a role and awareness at
such level when designing the LFB model is useful.
It could get worse with a mix and match of 16 bit, 8 bit, 64b and
variable  strings etc.
Yes, this is _not_ a protocol issue but a practical one nonetheless, so
if the model definition can save the efficiency, it benefits to do so.

to conclude:
In the LFBlib model, wherever you see the "reserved" fields it is to
deal with such issues.  The reserved fields also provide a nice
illustration on what bits can be used in later extensions without
affecting the wire format.

cheers,
jamal

>For ease of collecting information, I'v also included a Jamal's response inside.
>
> thanks,
> Weiming
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 17 Dec 2012 08:54:04 -0500

Sorry, didnt complete my explanation, addendum below:

On Mon, Dec 17, 2012 at 7:06 AM, Jamal Hadi Salim <[email-masked]> wrote:
[..]
> Say I had a naive component definition of struct {id=1, uchar; id =2, uint32}

[..]

> still have the 3B pad at the end but now the 32b field is efficiently

i.e above suggests the model should define struct as:
struct {id=1, uint32; id =2, uchar}
We will have a 3B pad at the end for a TLV or ILV. So
you could define it in the XML as:
struct {id=1, uint32; id =2, uchar, id 3 uchar resv0, id=4 int16 resv1}

Or we could also keep the same constructs as before and redefine as:
struct {id=1, uchar; id=2(optional) uchar resv0, id=2(optional) int16
resv1, id 2= uint32}
But now by defining things as optional appearing, you cant use a TLV
to send the
struct and youve lost the efficiency you went looking for.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 21 Dec 2012 16:24:49 +0800

Hi Andrian and others,

On the stat counters, RFC1155 difines couters for MIB by a text description, as:

3.2.3.3.  Counter
   This application-wide type represents a non-negative integer which
   monotonically increases until it reaches a maximum value, when it
   wraps around and starts increasing again from zero.  This memo
   specifies a maximum value of 2^32-1 (4294967295 decimal) for counters.

While YANG model defines some types of counters like: 
       +-----------------------+--------------------------------+
        | YANG type             | Equivalent SMIv2 type (module) |
        +-----------------------+--------------------------------+
        | counter32             | Counter32 (SNMPv2-SMI)         |
        | zero-based-counter32  | ZeroBasedCounter32 (RMON2-MIB) |
        | counter64             | Counter64 (SNMPv2-SMI)         |
        | zero-based-counter64  | ZeroBasedCounter64 (HCNUM-TC)  |

From all these definitions, we can see that all are still based on an integer of 32 or 64.  I just think we might only need a description like RFC1155 to indicate that all components for statistic counters purpose should monotonically increase and wrap till .... But to unlimit implementations, I suggest not limiting couters to 32bits only. I also tend not to define a specific 'counter' element in the ForCES FE model (actually it is insufficient to define a new counter type for stat purpose, rather to let FE model define a counter might be right if we do need such type).

thanks,
Weiming

---

From: t.petch <[email-masked]>
Date: Fri, 21 Dec 2012 11:17:13 +0000

Weimimg

I am sure you know that RFC1155, which you cite below, is somewhat
mature and that work on SMI defined further counters, as referenced by
YANG.  However, you may not be familiar with RFC4181 which gives
guidance on how counters should and should not be used, taking into
account discontinuities, so while the title of that RFC suggests that it
is aimed at an arcane group of reviewers, yet it is probably the best
description of what to do and not to do.

Tom Petch

----- Original Message -----
From: "Wang,Weiming" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2012 8:24 AM

> From all these definitions, we can see that all are still based on an
integer of 32 or 64.  I just think we might only need a description like
RFC1155 to indicate that all components for statistic counters purpose
should monotonically increase and wrap till .... But to unlimit
implementations, I suggest not limiting couters to 32bits only. I also
tend not to define a specific 'counter' element in the ForCES FE model
(actually it is insufficient to define a new counter type for stat
purpose, rather to let FE model define a counter might be right if we do
need such type).
> >>>  >> Maybe defining a specific atomic counter with full definition
on
> >>> wrap and
> >>>  >Again. Suggest to look at what MIB and YANG modules do for
wrapping
> >>> counters,
> >>> and special enumerated values in the statistic information type,
so we
> >>> havn't defined
> >>> a new atomic type.
> >>> Indeed there is no place to mention 'counter' in current lfb lib.
If we
> >>> think this is an

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 22 Dec 2012 14:18:04 +0800

Hi Adrian,

The IPv4PrefixTable is defined as an array. The  entry of the table is just the entry of the array. According to FE model (RFC5812), the order of entries arrays does not take other implicit meaning than as an array entry. 

I'v ever thought if we need to let the entry act (be defined) as a search key so as to fastly look up the table. To do so, we then need to define the entry as a specific element of the table (rather than a default entry) and then define the element as the 'search key' .  This seems not a good tradeoff.  In the end, I just gave up the thought.  

Properties of entry of an array is defined by RFC 5812(4.8.2). Info like entrycount, entry subscript space is available.

thanks,
Weiming