Subject: Re: [forces] AD review issue 3: on Figure 1 description (Editorial)

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 3 Jan 2013 14:21:09 +0800

Hi authors, Jamal and Adrian,

On this issue, I'm going to: 

1) move figure 1 to Section 7 and then remove the whole section "3.2.3.  Sample LFB Class Application" 

2) make LFB description more clear by adding a figure for every LFB to describe it. E.m., for EtherPHYCop  LFB,a figure as below may be added in some where in "Section 5.1.1.  EtherPHYCop": 

       +---------------+
        |                        |      EtherPHYIn
        |                        |<------------------------- 
        | EtherPHYCop |        
        |         LFB        |      EtherPHYOut
        |                        |-------------------------->          
        |                        |      
       +---------------+       
Figure 1. EtherPHYCop LFB

Because such change  is a relatively wide change in whole document, pls authors give your thought on whether approves the change.

thanks,
Weiming
 
----- Original Message ----- 
From: "Wang,Weiming" <[email-masked]>

> This is an editorial issue.  
> 
> thanks,
> Weiming 
> 
>> ----- Original Message ----- 
>> From: "Adrian Farrel" <[email-masked]>
>> 
>>> ---
>>> 
>>> 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 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. 
>> 
> 
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 3 Jan 2013 06:41:42 -0500

Hi Weiming,
This is fine with me - but as you note it means more work and likely a
new publication
given the size of the change.

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 3 Jan 2013 14:37:59 +0200

Greetings to all,

Wish everyone a happy new year! :)

About issue #3, I'm also fine with this. I think it's a better way to do
this.

However, can we keep section 3.2.3 and simplify it (with only 2 EtherPHyCop)
and a packet that enter one and exits the other in a sequential (loop-free)
figure, and also move the current figure 1 in section 7?
The reason is that I think there is value in having a figure before
describing a simple FE functionality before delving into more details - but
I agree the current one is very complex without having read the LFB
definitions.

Also I was thinking if it'd be better if we could somehow differentiate
singleton and group LFB ports with a different notation making it easier to
read. 

Example:
Horizontal
------> singleton
======> group

Vertical
/\
| singleton
\/

/\
|| group
\/

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jamal Hadi Salim
> Sent: Thursday, January 03, 2013 1:42 PM
> To: Wang,Weiming
> Cc: [email-masked]; [email-masked]
> Subject: Re: [forces] AD review issue 3: on Figure 1 description
> (Editorial)
> 
> Hi Weiming,
> new publication given the size of the change.
> 
> cheers,
> jamal
> 
> > 2) make LFB description more clear by adding a figure for every LFB
> to describe it. E.m., for EtherPHYCop  LFB,a figure as below may be
> added in some where in "Section 5.1.1.  EtherPHYCop":
> >
> >        +---------------+
> >         |                        |      EtherPHYIn
> > Because such change  is a relatively wide change in whole document,
> pls authors give your thought on whether approves the change.
> >
> > thanks,
> > Weiming
> >
> >>>> 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 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.
> >>>

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 12 Jan 2013 17:18:57 +0800

Hi all,

I'v tried to incorparate Evangelos's suggestion to modify the two sections. The result is shown below. Pls feel free to comments.

thanks,
Weiming

modified sections in document:
-------------
3.2.3.  Sample LFB Class Application

   Although Section 7 will present use cases for LFBs defined in this
   document, this section shows a simple sample LFB class application in
   advance so that readers can get a quick overlook of the LFB classes
   with the usage.

   Figure 1 shows a simple LFB processing path for Ethernet packets
   entered from Ethernet physical ports.

   +-----+                +------+
   |     |EtherPHYIn      |      |            from some LFB(s) which
   |     |<---------------|Ether |<---------- generate Ethernet
   |     |                |MACOut|            packets
   |     |                | LFB  |
   |Ether|                +------+
   |PHY  |                +------+
   |Cop  |                |      |
   |LFB  |EtherPHYOut     | Ether|            to some LFB(s) which
   |     |--------------->| MACIn|----------> may classify Ethernet
   |     |                |  LFB |            packets and do IP layer
   |     |                |      |            processing
   +-----+                +------+

                  Figure 1:  A simple sample LFB use case

   In the figure, Ethernet packets from outer networks enter via the
   EtherPHYCop LFB(Section 5.1.1), which describes Ethernet copper
   interface property(like the link speed) at physical layer.  After
   physical layer process, Ethernet packets are delivered to EtherMACIn
   LFB(Section 5.1.2) to describe its MAC layer processing
   functions(like locality check).  The packets after EtherMACIn LFB may
   require further processing to implement various functions(like IP
   layer forwarding),therefore some LFBs may follow the EtherMACIn LFB
   in topology to drscribe followed processing functions.

   Meanwile, packets generated by some LFB(s) may need to be submitted
   to ourter physical networks.  The process is described in the figure
   by an EtherMACOut LFB(Section 5.1.1) at MAC layer and the EtherPHYCop
   LFB at physical layer.
-------------

-------------
7.1.  IPv4 Forwarding

   Figure 2 shows the typical LFB processing path for an IPv4 unicast
   forwarding case with Ethernet media interfaces by use of the base LFB
   classes.  Note that in the figure, to focus on the IP forwarding
   function, some inputs or outputs of LFBs that are not related to the
   IPv4 forwarding function are not shown.  For example, an
   EtherClassifier LFB normally has two output ports: a "ClassifyOut"
   group output port and a "ExceptionOut" singleton output port, with
   the group port contains various port instances according to various
   classified packets types(Section 5.1.3).  While in this figure, only
   the IPv4 and IPv6 packet output port instances are shown for
   displaying the mere IPv4 forwarding processing function.

   +-----+                +------+
   |     |                |      |
   |     |<---------------|Ether |<----------------------------+
   |     |                |MACOut|                             |
   |     |                |      |                             |
   |Ether|                +------+                             |
   |PHY  |                                                     |
   |Cop  |            +---+                                    |
   |#1   |  +-----+   |   |----->IPv6 Packets                  |
   |     |  |     |   |   |                                    |
   |     |  |Ether|   |   | IPv4 Packets                       |
   |     |->|MACIn|-->|   |-+  +----+                          |
   +-----+  |     |   |   | |  |    |---> Multicast Packets    |
            +-----+   +---+ |  |    |        +-----+  +---+    |
                      Ether +->|    |------->|     |  |   |    |
      .           Classifier|  |    |Unicast |IPv4 |  |   |    |
      .                     |  |    |Packets |Ucast|->|   |--+ |
      .                     |  +----+        |LPM  |  |   |  | |
                      +---+ |   IPv4         +-----+  +---+  | |
            +-----+   |   | |   Validator              IPv4  | |
            |     |   |   | |                         NextHop| |
   +-----+  |Ether|   |   |-+ IPv4 Packets                   | |
   |     |->|MACIn|-->|   |                                  | |
   |     |  |     |   |   |----->IPv6 Packets                | |
   |Ether|  +-----+   +---+                                  | |
   |PHY  |           Ether               +----+              | |
   |Cop  |           Classifier          |    |   +-------+  | |
   |#n   |                +------+       |    |   |Ether  |  | |
   |     |                |      |       |    |<--|Encap  |<-+ |
   |     |                |      |<------|    |   |       |    |
   |     |<---------------|Ether |    ...|    |   +-------+    |
   |     |                |MACOut|   +---|    |                |
   |     |                |      |   |   +----+                |
   +-----+                +------+   | BasicMetadataDispatch   |
                                     +----------->-------------+

                Figure 2:  LFB use case for IPv4 forwarding

   In the LFB use case, a number of EtherPHYCop LFB(Section 5.1.1)
   instances are used to describe physical layer functions of the ports.
   PHYPortID metadata is generated by EtherPHYCop LFB and is used by all
   the subsequent downstream LFBs.  An EtherMACIn LFB(Section 5.1.2),
   which describe the MAC layer processing, follows every EtherPHYCop
   LFB.  The EtherMACIn LFB may do a locality check of MAC addresses if
   the CE configures the appropriate EtherMACIn LFB component.

   Ethernet packets out of the EtherMACIn LFB are sent to an
   EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified
   into network layer types like IPv4, IPv6, ARP, etc.  In the example
   use case, every physical Ethernet interface is associated with one
   Classifier instance; although not illustrated, it is also feasible
   that all physical interfaces are associated with only one Ethernet
   Classifier instance.

   EtherClassifier uses the PHYPortID metadata, the Ethernet type of the
   input packet, and VlanID (if present in the input Ethernet packets),
   to decide the packet network layer type and the LFB output port to
   the downstream LFB.  The EtherClassifier LFB also assigns a new
   logical port ID metadata to the packet for later use.  The
   EtherClassifier may also generate some new metadata for every packet
   like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by
   downstream LFBs.

   If a packet is classified as an IPv4 packet, it is sent downstream to
   an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet.  In
   the validator LFB, IPv4 packets are validated and are additionally
   classified into either IPv4 unicast packets or multicast packets.
   IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB
   (Section 5.3.1).

   The IPv4UcastLPM LFB is where the longest prefix match decision is
   made, and a next hop selection is selected.  The next hop ID metadata
   is generated by the IPv4UcastLPM LFB to be consumed downstream by the
   IPv4NextHop LFB (Section 5.3.2).

   The IPv4NextHop LFB uses the next hop ID metadata to do derive where
   the packet is to go next and the media encapsulation type for the
   port, etc.  The IPv4NextHop LFB generates the L3PortID metadata used
   to identify a next hop output physical/logical port.  In the example
   use case, the next hop output port is an Ethernet type; as a result,
   the packet and its L3 port ID metadata are sent downstream to an
   EtherEncap LFB (Section 5.1.4).

   The EtherEncap LFB encapsulates the incoming packet into an Ethernet
   frame.  A BasicMetadataDispatch LFB (Section 5.5.1) follows the
   EtherEncap LFB.  The BasicMetadataDispatch LFB is where packets are
   finally dispatched to different output physical/logical ports based
   on the L3PortID metadata sent to the LFB.
----------------

----- Original Message ----- 
From: "Haleplidis Evangelos" <[email-masked]>

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 14 Jan 2013 23:03:15 +0800

Hi all,

I tend to use a text as below to solve this issue, pls comment.

thanks,
Weiming

-----------
4.  Base Types

   The FE model [RFC5812] has specified predefined (built-in) atomic
   data-types as below:

   char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
   string, byte[N], boolean, octetstring[N], float16, float32, float64.

   Note that, unlike SNMP information model SMI([RFC2578]) , the FE model
   has not defined specific atomic data type for counting purpose.  This
   document follows not to define any specific counter types.  To describe
   LFB elements for packet statistics which actually require counters on
   packets, an unsigned integer, like an uint32 or an uint64 is adopted.
   This document states that any LFB element defined for counter purpose
   is specified to monotonically increase until it reaches a maximum
   value, when it wraps around and starts increasing again from zero.
   This document also states that it is implementation's issue how the
   unsigned integer element might be maintained to cope with issues like
   counter discontinuities when a counter wraps or is reset by any
   reasons.  If a CE is required to understand more meanings of the LFB
   element other than above stated, a private definition on the LFB
   element between CE and FE is required.
   ......

----- Original Message ----- 
From: "t.petch" <[email-masked]>
To: "Wang,Weiming" <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2012 7:17 PM
Subject: Re: [forces] AD review issue 2: On LAN speed definition andwhetherusing stat counter type

> 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
> 
> 
> From: "Wang,Weiming" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, December 21, 2012 8:24 AM
> 
>> 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
>>
>>
>> >>>  >> > 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.
>> >>>  >>
>> >>>  >> 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.
>> >>> '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: "Wang,Weiming" <[email-masked]>
Date: Sun, 27 Jan 2013 22:32:36 +0800

This issue is closed.

thanks,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 27 Jan 2013 22:33:37 +0800

The issue is closed.

thanks,
Weiming
  ----- Original Message ----- 
  From: Wang,Weiming 
  To: Haleplidis Evangelos ; 'Jamal Hadi Salim' 
  Cc: [email-masked] ; [email-masked] 
  Sent: Saturday, January 12, 2013 5:18 PM
  Subject: Re: [forces] AD review issue 3: on Figure 1 description (Editorial)

  Hi all,

  thanks,
  Weiming

     +-----+                +------+

  -------------
  7.1.  IPv4 Forwarding

     +-----+                +------+
     |     |                |      |

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 27 Jan 2013 22:43:53 +0800

So, there is no change to the IANA section and the issue is closed.

thanks,
Weiming

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

> 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
> 
> On 12/16/2012 10:34 PM, Wang,Weiming wrote:
>> 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
>>
>>>> ===
>>>> 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: Sun, 27 Jan 2013 22:47:55 +0800

So, the issue is closed with no text change.

thanks,
Weiming
----- Original Message ----- 

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 27 Jan 2013 22:56:18 +0800

So, no change to the text and to close the issue.

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>

> 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}
> 
> [..]
> 
>> 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.
> 
> 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
>