Subject: [forces] Update on draft-ietf-forces-lfb-lib

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 5 Jan 2013 19:21:50 -0000

Now that the various issues have been threaded separately, I'm going to pull
them back together so you can move on quickly. Feel free to split them out again
to follow up on any discussions.

#1 padding
I am completely unconvinced about everything you say :-) 
But it is clear to me you have thought about this hard and believe what you are
saying is correct.
I will not stand in the way of this issue.
No change needed.

#2a enumerations for line speed
If you guys have a preference for an enumeration, then let's go that way.
I think you have picked a system that requires new implementations to come back
to IANA or use magic numbers, but this is your choice. (Also please note that
RFC 3471 did not use an enumeration for bandwidth - it gives a list of FP values
to save people screwing up the calculations.)
No change needed.

#2b counters for stats
Looks like Weiming has some proposals for minor changes to clean this up. 
And Tom recommended looking to RFC 4181 for guidance.
I would also like you to either state that discontinuities and wraps are not
recorded, or to add objects to handle them.
Document change needed.

#3 description of figure 3
Weiming has a proposal and Evangelos made a counter-proposal.
This would be fine with me. 
Document change needed.

#4 IANA specification required and private use
I think what you have here is very similar to the case for IPFIX. You want to
encourage new uses of the protocol to attach to new devices and retrieve or set
previously-unthought-of information. However, it would be really nice if new
extensions were documented in RFCs and recorded by IANA.
If what you have is really the split that the WG wants, and the issue has been
thought about, then that is fine.
No change needed.

#5 description of FIB model
Weiming has a proposal modified by Jamal.
This is fine by me.
Document change needed.

#6 ordering of IPv4PrefixTable entries
The order of forwarding entries in hardware may or may not be important
depending on the search/match algorithm in use.
That, in turn, may impact the way that the entries have to be loaded into
hardware.
As I understand your conversation, you have determined that it is entirely up to
the hardware to determine how to load the IPv4PrefixTable entries into the
forwarding engine, and thus how to match on them. In other words (as you said),
there is no special meaning implicit in the ordering. You say that this is
already defined in 5812, so I agree it doesn't need to be restated here.
No change needed.

Hope this gives you everything you need to revise and re-post the I-D.

Cheers,
Adrian

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 7 Jan 2013 20:16:49 +0800

Appreciate the clean summary made by AD.

I will update the document ASAP after some business on the semester end which I'm in charge of and might take week or so. Sorry. 

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: Wed, 16 Jan 2013 23:04:33 +0800

Hi all,

I"v tried to modify the synopsises of the XML part. Below is the base type XML file, which I pasted directly to this message in hope that you may review it easily. I know someone dislike to open another file :) 

thanks,
Weiming

--------------
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     provides="BaseTypeLibrary">
   <frameDefs>
      <frameDef>
         <name>EthernetAll</name>
         <synopsis>Packet with any Ethernet type</synopsis>
      </frameDef>
      <frameDef>
         <name>EthernetII</name>
         <synopsis>Packet with Ethernet II type</synopsis>
      </frameDef>
      <frameDef>
         <name>ARP</name>
         <synopsis>ARP packet</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv4</name>
         <synopsis>IPv4 packet</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv6</name>
         <synopsis>IPv6 packet</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv4Unicast</name>
         <synopsis>IPv4 unicast packet</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv4Multicast</name>
         <synopsis>IPv4 multicast packet</synopsis>
      </frameDef>   
      <frameDef>
         <name>IPv6Unicast</name>
         <synopsis>IPv6 unicast packet</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv6Multicast</name>
         <synopsis>IPv6 multicast packet</synopsis>
      </frameDef>   
      <frameDef>
         <name>Arbitrary</name>
         <synopsis>Any type of packet</synopsis>
      </frameDef>   
   </frameDefs>
   <dataTypeDefs>
      <dataTypeDef>
         <name>IPv4Addr</name>
         <synopsis>IPv4 address</synopsis>
         <typeRef>byte[4]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6Addr</name>
         <synopsis>IPv6 address</synopsis>
         <typeRef>byte[16]</typeRef>
      </dataTypeDef>   
      <dataTypeDef>
         <name>IEEEMAC</name>
         <synopsis>IEEE MAC address</synopsis>
         <typeRef>byte[6]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>LANSpeedType</name>
        <synopsis>LAN speed type</synopsis>
        <atomic>
         <baseType>uint32</baseType>
         <specialValues>
           <specialValue value="0x00000000">
            <name>LAN_SPEED_NONE</name>
            <synopsis>Nothing connected</synopsis>
           </specialValue>         
           <specialValue value="0x00000001">
            <name>LAN_SPEED_10M</name>
            <synopsis>10M Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000002">
            <name>LAN_SPEED_100M</name>
            <synopsis>100M Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000003">
            <name>LAN_SPEED_1G</name>
            <synopsis>1G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000004">
            <name>LAN_SPEED_10G</name>
            <synopsis>10G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000005">
            <name>LAN_SPEED_40G</name>
            <synopsis>40G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000006">
            <name>LAN_SPEED_100G</name>
            <synopsis>100G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000007">
            <name>LAN_SPEED_400G</name>
            <synopsis>400G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000008">
            <name>LAN_SPEED_1T</name>
            <synopsis>1T Ethernet</synopsis>
           </specialValue>           
           <specialValue value="0x00000009">
            <name>LAN_SPEED_OTHER</name>
            <synopsis>Other LAN speed type</synopsis>
           </specialValue>
           <specialValue value="0x0000000A">
            <name>LAN_SPEED_AUTO</name>
            <synopsis>LAN speed by auto negotiation</synopsis>
           </specialValue>
         </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>DuplexType</name>
        <synopsis>Duplex mode type</synopsis>
        <atomic>
         <baseType>uint32</baseType>
         <specialValues>
           <specialValue value="0x00000001">
            <name>Auto</name>
            <synopsis>Auto negotiation</synopsis>
           </specialValue>
           <specialValue value="0x00000002">
            <name>HalfDuplex</name>
            <synopsis>Half duplex</synopsis>
           </specialValue>
           <specialValue value="0x00000003">
            <name>FullDuplex</name>
            <synopsis>Full duplex</synopsis>
           </specialValue>
         </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>PortStatusType</name>
        <synopsis>
          Type for port status, used for both administrative and 
          operative status.
        </synopsis>
        <atomic>
         <baseType>uchar</baseType>
         <specialValues>
           <specialValue value="0">
            <name>Disabled</name>
            <synopsis>Port disabled</synopsis>
           </specialValue>
           <specialValue value="1">
            <name>Up</name>
            <synopsis>Port up</synopsis>
           </specialValue>
           <specialValue value="2">
            <name>Down</name>
            <synopsis>Port down</synopsis>
           </specialValue>
         </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>MACInStatsType</name>
         <synopsis>
           Data type defined for statistics in EtherMACIn LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>NumPacketsReceived</name>
               <synopsis>Number of packets received</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>NumPacketsDropped</name>
               <synopsis>Number of packets dropped</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>MACOutStatsType</name>
         <synopsis>
           Data type defined for statistics in EtherMACOut LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>NumPacketsTransmitted</name>
               <synopsis>Number of packets transmitted</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>NumPacketsDropped</name>
               <synopsis>Number of packets dropped</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherDispatchEntryType</name>
         <synopsis>
           Data type defined for entry of Ethernet dispatch  
           table in EtherClassifier LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>LogicalPortID</name>
               <synopsis>Logical port ID</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>EtherType</name>
               <synopsis>
                The Ethernet type of the Ethernet packet.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="3">
               <name>Reserved</name>
               <synopsis>
               A reserved bit space mainly for purpose of padding 
               and packing efficiency.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>            
            <component componentID="4">
               <name>LFBOutputSelectIndex</name>
                <synopsis>
                  Index for a packet to select an instance in the
                  group output port of EtherClassifier LFB to output.
                </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>   
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherDispatchTableType</name>
         <synopsis>
           Data type defined for Ethernet dispatch table in  
           EtherClassifier LFB. The table is composed of an array
           of entries with EtherDispatchEntryType data type. 
         </synopsis>
         <array type="variable-size">
           <typeRef>EtherDispatchEntryType</typeRef>
         </array>
      </dataTypeDef>  
      <dataTypeDef>
         <name>VlanIDType</name>
         <synopsis>Data type for VLAN ID</synopsis>
         <atomic>
         <baseType>uint16</baseType>
           <rangeRestriction>
              <allowedRange min="0" max="4095"/>
            </rangeRestriction>
         </atomic>
       </dataTypeDef>
      <dataTypeDef>
         <name>VlanPriorityType</name>
         <synopsis>Data type for VLAN priority</synopsis>
         <atomic>
         <baseType>uchar</baseType>
           <rangeRestriction>
              <allowedRange min="0" max="7"/>
           </rangeRestriction>       
         </atomic>
      </dataTypeDef>       
      <dataTypeDef>
         <name>VlanInputTableEntryType</name>
         <synopsis>
           Data type for entry of VLAN input table in EtherClassifier
           LFB. Each entry of the table contains an incoming port ID, 
           a VLAN ID and a logical port ID. Every input packet is 
           assigned with a new logical port ID according to the 
           packet incoming port ID and the VLAN ID.
           </synopsis>
         <struct>
            <component componentID="1">
               <name>IncomingPortID</name>
               <synopsis>The incoming port ID</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>VlanID</name>
               <synopsis>The VLAN ID</synopsis>
               <typeRef>VlanIDType</typeRef>
            </component>
            <component componentID="3">
               <name>Reserved</name>
               <synopsis>
               A reserved bit space mainly for purpose of padding 
               and packing efficiency.
               </synopsis>
               <typeRef>uint16</typeRef>  
            </component>          
            <component componentID="4">
               <name>LogicalPortID</name>
               <synopsis>The logical port ID</synopsis>
               <typeRef>uint32</typeRef>
            </component>                           
         </struct>
      </dataTypeDef>  
      <dataTypeDef>
         <name>VlanInputTableType</name>
         <synopsis>
           Data type for the VLAN input table in EtherClassifier
           LFB. The table is composed of an array of entries with 
           VlanInputTableEntryType. 
         </synopsis>
         <array type="variable-size">
           <typeRef>VlanInputTableEntryType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherClassifyStatsType</name>
         <synopsis>
           Data type for entry of statistics table in EtherClassifier 
           LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>EtherType</name>
               <synopsis>
                The Ethernet type of the Ethernet packet.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="2">
               <name>Reserved</name>
               <synopsis>
               A reserved bit space mainly for purpose of padding 
               and packing efficiency.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="3">
               <name>PacketsNum</name>
               <synopsis>Packets number</synopsis>
               <typeRef>uint64</typeRef>
            </component>                           
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherClassifyStatsTableType</name>
         <synopsis>
           Data type for statistics table in EtherClassifier LFB.
         </synopsis>
         <array type="variable-size">
           <typeRef>EtherClassifyStatsType</typeRef>
         </array>
      </dataTypeDef>        
      <dataTypeDef>
         <name>IPv4ValidatorStatsType</name>
         <synopsis>
           Data type for statistics in IPv4validator LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>badHeaderPkts</name>
               <synopsis>Number of packets with bad header</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>badTotalLengthPkts</name>
               <synopsis>
                 Number of packets with bad total length
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>badTTLPkts</name>
               <synopsis>Number of packets with bad TTL</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="4">
               <name>badChecksumPkts</name>
               <synopsis>Number of packets with bad checksum</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>   
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6ValidatorStatsType</name>
         <synopsis>
           Data type for statistics in IPv6validator LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>badHeaderPkts</name>
               <synopsis>Number of packets with bad header</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>badTotalLengthPkts</name>
               <synopsis>
               Number of packets with bad total length.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>badHopLimitPkts</name>
               <synopsis>
               Number of packets with bad hop limit.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>   
      </dataTypeDef>            
      <dataTypeDef>
         <name>IPv4PrefixInfoType</name>
         <synopsis>Data type for entry of IPv4 longest prefix match
          table in IPv4UcastLPM LFB. The destination IPv4 address 
          of every input packet is used as a search key to look up 
          the table to find out a next hop selector.</synopsis>
         <struct>
            <component componentID="1">
               <name>IPv4Address</name>
               <synopsis>The destination IPv4 address</synopsis>
               <typeRef>IPv4Addr</typeRef>
            </component>
            <component componentID="2">
               <name>Prefixlen</name>
               <synopsis>The prefix length</synopsis>
               <atomic>
                  <baseType>uchar</baseType>
                  <rangeRestriction>
                     <allowedRange min="0" max="32"/>
                  </rangeRestriction>
               </atomic>
            </component>
            <component componentID="3">
               <name>ECMPFlag</name>
               <synopsis>The ECMP flag</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>
                         ECMP false, indicating the route 
                         does not have multiple next hops.
                        </synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>
                          ECMP true, indicating the route 
                          has multiple next hops. 
                        </synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>
            <component componentID="4">
               <name>DefaultRouteFlag</name>
               <synopsis>Default route flag</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>
                          Default route false, indicating the 
                          route is not a default route. 
                        </synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis> 
                          Default route true, indicating the 
                          route is a default route. 
                        </synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>           
            <component componentID="5">
               <name>Reserved</name>
               <synopsis>
               A reserved bit space mainly for purpose of padding 
               and packing efficiency.
               </synopsis>
               <typeRef>uchar</typeRef>
            </component>            
            <component componentID="6">
               <name>HopSelector</name>
               <synopsis>
                 The HopSelector produced by the prefix matching LFB,
                 which will be output to downstream LFB to find next
                 hop information.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>        
      <dataTypeDef>
         <name>IPv4PrefixTableType</name>
         <synopsis>
           Data type for IPv4 longest prefix match table in 
           IPv4UcastLPM LFB. Entry of the table is 
           of IPv4PrefixInfoType data type. 
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv4PrefixInfoType</typeRef>
         </array>
      </dataTypeDef>          
      <dataTypeDef>
         <name>IPv4UcastLPMStatsType</name>
         <synopsis>
          Data type for statistics in IPv4UcastLPM LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>InRcvdPkts</name>
               <synopsis>Number of received input packets.</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>FwdPkts</name>
               <synopsis>Number of forwarded packets.</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>NoRoutePkts</name>
               <synopsis>
                Number of packets with no route found.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>   
      <dataTypeDef>
         <name>IPv6PrefixInfoType</name>
         <synopsis>Data type for entry of IPv6 longest prefix match
          table in IPv6UcastLPM LFB. The destination IPv6 address 
          of every input packet is used as a search key to look up 
          the table to find out a next hop selector.</synopsis>
         <struct>
            <component componentID="1">
               <name>IPv6Address</name>
               <synopsis>The destination IPv6 address</synopsis>
               <typeRef>IPv6Addr</typeRef>
            </component>
            <component componentID="2">
               <name>Prefixlen</name>
               <synopsis>The prefix length</synopsis>
               <atomic>
                  <baseType>uchar</baseType>
                  <rangeRestriction>
                     <allowedRange min="0" max="32"/>
                  </rangeRestriction>
               </atomic>
            </component>
            <component componentID="3">
               <name>ECMPFlag</name>
               <synopsis>ECMP flag</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>ECMP false</synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>ECMP true</synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>
            <component componentID="4">
               <name>DefaultRouteFlag</name>
               <synopsis>Default route flag</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>Default false</synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>Default route true</synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>           
            <component componentID="5">
               <name>Reserved</name>
               <synopsis>
               A reserved bit space mainly for purpose of padding 
               and packing efficiency.
               </synopsis>
               <typeRef>uchar</typeRef>
            </component>            
            <component componentID="6">
               <name>HopSelector</name>
               <synopsis>
                 The HopSelector produced by the prefix matching LFB,
                 which will be output to downstream LFB to find next
                 hop information.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6PrefixTableType</name>
         <synopsis>
           Data type for IPv6 longest prefix match table in 
           IPv6UcastLPM LFB. Entry of the table is 
           of IPv6PrefixInfoType data type. 
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv6PrefixInfoType</typeRef>
         </array>
      </dataTypeDef>       
      <dataTypeDef>
         <name>IPv6UcastLPMStatsType</name>
         <synopsis>Data type for statistics in IPv6UcastLPM LFB</synopsis>
         <struct>
            <component componentID="1">
               <name>InRcvdPkts</name>
               <synopsis>Number of received input packets</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>FwdPkts</name>
               <synopsis>Number of forwarded packets</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>NoRoutePkts</name>
               <synopsis>
                Number of packets with no route found.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4NextHopInfoType</name>
         <synopsis>
           Data type for entry of IPv4 next hop information table
           in IPv4NextHop LFB. The table uses a hop selector
           received from upstream LFB as a search key to look up
           index of the table to find the next hop information. 
         </synopsis>
         <struct>
            <component componentID="1">
               <name>L3PortID</name>
               <synopsis>
                The ID of the logical output port that is to pass
                onto downstream LFB, indicating what port to the 
                neighbor is as defined by L3. 
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>MTU</name>
               <synopsis>
                Maximum Transmission Unit for outgoing port
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>NextHopIPAddr</name>
               <synopsis>The next hop IPv4 address</synopsis>
               <typeRef>IPv4Addr</typeRef>
            </component>
            <component componentID="4">
               <name>MediaEncapInfoIndex</name>
               <synopsis>
                 The index passed onto a downstream encapsulation 
                 LFB, used there as a search key to lookup further
                 encapsulation information.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="5">
               <name>LFBOutputSelectIndex</name>
                <synopsis>
                  The index for the IPv4NextHop LFB to choose an instance
                  in the group output port of the LFB to output. 
                </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4NextHopTableType</name>
         <synopsis>
           Data type for IPv4 next hop table in IPv4NextHop LFB. 
           Entry of the table is of IPv4NextHopInfoType data type.
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv4NextHopInfoType</typeRef>
         </array>
      </dataTypeDef>        
      <dataTypeDef>
         <name>IPv6NextHopInfoType</name>
         <synopsis>
           Data type for entry of IPv6 next hop information table
           in IPv6NextHop LFB. The table uses a hop selector
           received from upstream LFB as a search key to look up
           index of the table to find the next hop information.
          </synopsis>
         <struct>
            <component componentID="1">
               <name>L3PortID</name>
               <synopsis> 
                The ID of the logical output port that is to pass
                onto downstream LFB, indicating what port to the 
                neighbor is as defined by L3. 
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>MTU</name>
               <synopsis>
                 Maximum Transmission Unit for outgoing port
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>NextHopIPAddr</name>
               <synopsis>The next hop IPv6 address</synopsis>
               <typeRef>IPv6Addr</typeRef>
            </component>
            <component componentID="4">
               <name>MediaEncapInfoIndex</name>
               <synopsis>
                 The index passed onto a downstream encapsulation 
                 LFB, used there as a search key to lookup further
                 encapsulation information.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="5">
               <name>LFBOutputSelectIndex</name>
                <synopsis>
                 The index for the IPv6NextHop LFB to choose an instance
                 in the group output port of the LFB to output. 
                </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef> 
      <dataTypeDef>
         <name>IPv6NextHopTableType</name>
         <synopsis>
           Data type for IPv6 next hop table in IPv6NextHop LFB. 
           Entry of the table is of IPv6NextHopInfoType data type.
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv6NextHopInfoType</typeRef>
         </array>
      </dataTypeDef>          
      <dataTypeDef>
         <name>EncapTableEntryType</name>
         <synopsis>
           Data type for entry of Ethernet encapsulation table in 
           EtherEncap LFB. The LFB uses the MediaEncapInfoIndex
           received from upstream LFB as index of the table to 
           find encapsulation information of every packet.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>DstMac</name>
               <synopsis>
                 Destination MAC address for Ethernet encapsulation of 
                 the packet.
               </synopsis>
               <typeRef>IEEEMAC</typeRef>
            </component>
            <component componentID="2">
               <name>SrcMac</name>
               <synopsis>
                 Source MAC address for Ethernet encapsulation of the 
                 packet. 
               </synopsis>
               <typeRef>IEEEMAC</typeRef>
            </component>
            <component componentID="3">
               <name>VlanID</name>
               <synopsis>The VLAN ID assigned to the packet</synopsis>
               <typeRef>VlanIDType</typeRef>
            </component>
             <component componentID="4">
               <name>Reserved</name>
               <synopsis>
                A reserved bit space mainly for purpose of padding 
                and packing efficiency.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>           
            <component componentID="5">
               <name>L2PortID</name>
               <synopsis>
                 The L2 logical output port ID for the packet.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef> 
      <dataTypeDef>
         <name>EncapTableType</name>
         <synopsis>
           Data type for Ethernet encapsulation table in Etherencap 
           LFB. Entry of the table is of EncapTableEntryType data 
           type.
         </synopsis>
         <array type="variable-size">
           <typeRef>EncapTableEntryType</typeRef>
         </array>
      </dataTypeDef>        
      <dataTypeDef>
         <name>MetadataDispatchType</name>
         <synopsis>
           Data type for entry of metadata dispatch table used in 
           BasicMetadataDispatch LFB. The LFB uses a metadata value 
           as a search key to look up the table to find an index of
           the LFB group output port to output the packet.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>MetadataValue</name>
               <synopsis>The value of the dispatch metadata</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>OutputIndex</name>
               <synopsis>
                 Index of a group output port for outgoing packets.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>   
      </dataTypeDef>
      <dataTypeDef>
         <name>MetadataDispatchTableType</name>
         <synopsis>
           Data type for metadata dispatch table used in 
           BasicMetadataDispatch LFB. Metadata value of 
           the table is also defined as a content key field.
         </synopsis>
         <array type="variable-size">
           <typeRef>MetadataDispatchType</typeRef>
           <contentKey contentKeyID="1">
           <contentKeyField>MetadataValue</contentKeyField>
           </contentKey>           
         </array>
      </dataTypeDef> 
      <dataTypeDef>
         <name>SchdDisciplineType</name>
         <synopsis>Scheduling discipline type</synopsis>
         <atomic>
            <baseType>uint32</baseType>
            <specialValues>
               <specialValue value="1">
                  <name>RR</name>
                  <synopsis>
                    Round Robin scheduling discipline 
                  </synopsis>
               </specialValue>            
            </specialValues>
         </atomic>
      </dataTypeDef>   
      <dataTypeDef>
         <name>QueueStatsType</name>
         <synopsis>
           Data type for entry of queue statistics table in 
           GenericScheduler LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>QueueID</name>
               <synopsis>The input queue ID</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>QueueDepthInPackets</name>
               <synopsis>Current queue depth in packets</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>QueueDepthInBytes</name>
               <synopsis>Current queue depth in bytes</synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>   
      </dataTypeDef>  
      <dataTypeDef>
         <name>QueueStatsTableType</name>
         <synopsis>
           Data type for queue statistics table in GenericScheduler 
           LFB. Entry of the table is of QueueStatsType data type.
         </synopsis>
         <array type="variable-size">
           <typeRef>QueueStatsType</typeRef>
         </array>
      </dataTypeDef>      
   </dataTypeDefs>
   <metadataDefs>
      <metadataDef>
         <name>PHYPortID</name>
         <synopsis>Metadata indicating physical port ID</synopsis>
         <metadataID>1</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>SrcMAC</name>
         <synopsis>Metadata indicating source MAC address</synopsis>
         <metadataID>2</metadataID>
         <typeRef>IEEEMAC</typeRef>
      </metadataDef>
      <metadataDef>
         <name>DstMAC</name>
         <synopsis>
           Metadata indicating destination MAC address.
         </synopsis>
         <metadataID>3</metadataID>
         <typeRef>IEEEMAC</typeRef>
      </metadataDef>
      <metadataDef>
         <name>LogicalPortID</name>
         <synopsis>Metadata of logical port ID</synopsis>
         <metadataID>4</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>EtherType</name>
         <synopsis>Metadata indicating Ethernet type</synopsis>
         <metadataID>5</metadataID>
         <typeRef>uint16</typeRef>
      </metadataDef>            
      <metadataDef>
         <name>VlanID</name>
         <synopsis>Metadata of VLAN ID</synopsis>
         <metadataID>6</metadataID>
         <typeRef>VlanIDType</typeRef>
      </metadataDef>
      <metadataDef>
         <name>VlanPriority</name>
         <synopsis>Metadata of VLAN priority</synopsis>
         <metadataID>7</metadataID>
         <typeRef>VlanPriorityType</typeRef>
      </metadataDef>
      <metadataDef>
         <name>NextHopIPv4Addr</name>
         <synopsis>
           Metadata representing a next hop IPv4 address 
         </synopsis>
         <metadataID>8</metadataID>
         <typeRef>IPv4Addr</typeRef>
      </metadataDef>
      <metadataDef>
         <name>NextHopIPv6Addr</name>
         <synopsis> 
           Metadata representing a next hop IPv6 address 
         </synopsis>
         <metadataID>9</metadataID>
         <typeRef>IPv6Addr</typeRef>
      </metadataDef>   
      <metadataDef>
         <name>HopSelector</name>
         <synopsis>Metadata indicating a hop selector</synopsis>
         <metadataID>10</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>ExceptionID</name>
         <synopsis>
           Metadata indicating exception types for exceptional cases 
           during packet processing.
         </synopsis>
         <metadataID>11</metadataID>
         <atomic>
            <baseType>uint32</baseType>
            <specialValues>
                <specialValue value="0">
                  <name>AnyUnrecognizedExceptionCase</name>
                  <synopsis>Any unrecognized exception case</synopsis>
                  </specialValue>
                <specialValue value="1">
                  <name>ClassifyNoMatching</name>
                  <synopsis>
                   Exception case: no matching of tables in 
                   EtherClassifier LFB.
                  </synopsis>
                </specialValue>
                <specialValue value="2">
                  <name>MediaEncapInfoIndexInvalid</name>
                  <synopsis>
                   Exception case: the MediaEncapInfoIndex value of
                   the packet is invalid and cannot be allocated in
                   the EncapTable in EtherEncap LFB. 
                  </synopsis>
                </specialValue> 
                <specialValue value="3">
                  <name>EncapTableLookupFailed</name>
                  <synopsis>
                   Exception case: the packet fails lookup of the 
                   EncapTable table in EtherEncap LFB even though the 
                   MediaEncapInfoIndex is valid.
                  </synopsis>
                </specialValue>               
                <specialValue value="4">
                  <name>BadTTL</name>
                  <synopsis>
                   Exception case: packet with expired TTL</synopsis>
                </specialValue>
                <specialValue value="5">
                  <name>IPv4HeaderLengthMismatch</name>
                  <synopsis>
                   Exception case: packet with header length more
                   than 5 words.
                  </synopsis>
                </specialValue>
                <specialValue value="6">
                   <name>RouterAlertOptions</name>
                   <synopsis>
                    Exception case: packet IP head includes router
                    alert options.
                   </synopsis>
                </specialValue>        
                <specialValue value="7">
                   <name>IPv6HopLimitZero</name>
                   <synopsis>
                    Exception case: packet with the hop limit to zero.
                    </synopsis>
                </specialValue>
                <specialValue value="8">
                   <name>IPv6NextHeaderHBH</name>
                   <synopsis>
                    Exception case: packet with next header set to 
                    Hop-by-Hop.
                   </synopsis>
                </specialValue>
                <specialValue value="9">                
                   <name>SrcAddressExecption</name>
                   <synopsis>
                    Exception case: packet with exceptional source 
                    address.
                   </synopsis>
                </specialValue>
                <specialValue value="10">
                   <name>DstAddressExecption</name>
                   <synopsis>
                    Exception case: packet with exceptional 
                    destination address.
                   </synopsis>
                </specialValue>
                <specialValue value="11">
                   <name>LPMLookupFailed</name>
                   <synopsis>
                    Exception case: packet failed the LPM table 
                    lookup in a prefix match LFB.
                   </synopsis>
                </specialValue>   
                <specialValue value="12">
                   <name>HopSelectorInvalid</name>
                   <synopsis>
                    Exception case: HopSelector for the packet is 
                    invalid.
                   </synopsis>
                </specialValue> 
                <specialValue value="13">
                   <name>NextHopLookupFailed</name>
                   <synopsis>
                    Exception case: packet failed lookup of a next hop
                    table even though HopSelector is valid.
                   </synopsis>
                </specialValue>  
                <specialValue value="14">
                   <name>FragRequired</name>
                   <synopsis>
                    Exception case: packet fragmentation is required 
                   </synopsis>
                </specialValue>   
                <specialValue value="15">
                   <name>MetadataNoMatching</name>
                   <synopsis>
                    Exception case: there is no matching when looking
                    up the metadata dispatch table in 
                    BasicMetadataDispatch LFB.
                   </synopsis>
                </specialValue>              
             </specialValues>
          </atomic>
      </metadataDef>   
      <metadataDef>         
          <name>ValidateErrorID</name>
          <synopsis>
            Metadata indicating error types when a packet passes 
            validation process. 
          </synopsis>
          <metadataID>12</metadataID>
          <atomic>
             <baseType>uint32</baseType>
             <specialValues>
                <specialValue value="0">
                   <name>AnyUnrecognizedValidateErrorCase</name>
                   <synopsis>
                     Any unrecognized validate error case. 
                   </synopsis>
                </specialValue>
                <specialValue value="1">
                   <name>InvalidIPv4PacketSize</name>
                   <synopsis>
                    Error case: packet length reported by the link
                    layer is less than 20 bytes. 
                   </synopsis>
                </specialValue>
                <specialValue value="2">
                   <name>NotIPv4Packet</name>
                   <synopsis>
                    Error case: packet is not IP version 4</synopsis>
                </specialValue>
                <specialValue value="3">
                   <name>InvalidIPv4HeaderLengthSize</name>
                   <synopsis>
                    Error case: packet with header length field in
                    the header less than 5 words. 
                   </synopsis>
                </specialValue>
                <specialValue value="4">
                   <name>InvalidIPv4LengthFieldSize</name>
                   <synopsis>
                    Error case: packet with total length field in the
                    header less than 20 bytes. 
                   </synopsis>
                </specialValue>                
                <specialValue value="5">
                   <name>InvalidIPv4Checksum</name>
                   <synopsis>
                    Error case: packet with invalid checksum.
                    </synopsis>
                </specialValue>              
                <specialValue value="6">
                   <name>InvalidIPv4SrcAddr</name>
                   <synopsis>
                    Error case: packet with invalid IPv4 source 
                    address.
                   </synopsis>
                </specialValue>
                <specialValue value="7">
                   <name>InvalidIPv4DstAddr</name>
                   <synopsis>
                    Error case: packet with invalid IPv4 destination
                    address.
                   </synopsis>
                </specialValue>
                <specialValue value="8">
                   <name>InvalidIPv6PacketSize</name>
                   <synopsis>
                    Error case: packet size is less than 40 bytes. 
                   </synopsis>
                </specialValue>
                <specialValue value="9">
                   <name>NotIPv6Packet</name>
                   <synopsis>
                    Error case: packet is not IP version 6
                    </synopsis>
                </specialValue>
                <specialValue value="10">
                   <name>InvalidIPv6SrcAddr</name>
                   <synopsis>
                    Error case: packet with invalid IPv6 source 
                    address.
                   </synopsis>
                </specialValue>
                <specialValue value="11">
                   <name>InvalidIPv6DstAddr</name>
                   <synopsis>
                    Error case: packet with invalid IPv6 destination 
                    address.
                   </synopsis>
                </specialValue>
             </specialValues>
          </atomic>
      </metadataDef>    
      <metadataDef>
         <name>L3PortID</name>
         <synopsis>
           Metadata indicating ID of an L3 logical port 
         </synopsis>
         <metadataID>13</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>RedirectIndex</name>
         <synopsis>
           Metadata that CE sends to RedirectIn LFB, indicating 
           th group output port index of the LFB. 
         </synopsis>         
         <metadataID>14</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>MediaEncapInfoIndex</name>
         <synopsis>
           A search key a packet uses to look up a table to select
           an encapsulation media. 
         </synopsis>
         <metadataID>15</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
   </metadataDefs>
</LFBLibrary>
------------------
The End.

---

From: Chuanhuang <[email-masked]>
Date: Thu, 17 Jan 2013 16:14:57 +0800

I found the MAC address type wasn't modified yet.
According previous suggestion, the type will be defined 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>

The following is the latest base type XML definition. 
The attachment is its XML file.

Yours,
Chuanhuang

         <union>
              <name>MAC48 </name>
              <synopsis>MAC-48</synopsis>
              <typeRef> byte[6]</typeRef>
               <name> EUI64</name>
               <synopsis>EUI-64</synopsis>
               <typeRef> byte[8]</typeRef>
        </union>

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 17 Jan 2013 21:32:27 +0800

Hi all,

I'm talking with Chuanhuang on some worry about the use of the union IEEEMAC. 

Because it introduces a variable byte size and an extra component ID, I'm just worrying if it will have side effect on data packing in ForCES protocol, and how the component ID will be generated and consumbed. Also, it seems the use of the union IEEEMAC may affect the use of 'reserved' idea, because it actually let the reserved field loses packing efficiency. This is like in the data type of 'EncapTableEntryType'. 

I'm still thinking of this issue.... Any thoughts?

thanks,
Weiming

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 17 Jan 2013 08:42:53 -0500

Ok, so a little confused because i dont remember the context of the discussion.
Why are we being so clever and making this a union?
MAC48 seems to be the more commonly used as "IEEE MAC address".
Can we have the EUI64 as maybe IEEEMACEUI64 and as a separate component?

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 17 Jan 2013 22:10:11 +0800

I'm thinking it may be out of our current power to hope to have a universal IEEE Mac data type. It may makes things complex. It is also out of my thought we define a separate component when we need to define a IEEEMAC component. Just how can we do?

It seems we now may have to confess that when we define  a  xxxLFB with a component of IEEE MAC-48, the LFB can only accept the 48 bit MAC. If we need to accept 48 or 64 MAC packets, we need to later define a  specific 'MAC48/64 compatible xxxLFB' then, in which we may adopt the union MAC type. Whereas, we do need more work and thinking. 

thanks,
Weiming

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 17 Jan 2013 09:31:10 -0500

Weiming,

Can we not define a new datatype?
I have read through this thread and i cant see where the need for
"universal" IEEE MAC is needed.

cheers,
jamal

---

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

So, we'l finialy defer the modification of the IEEE MAC type change in this update and close this issue.

thanks,
Weiming

---

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

I think all the issues AD pointed has been addressed and a new v10 is ready to submit to IETF very soon. Pls feel free to show your comments if anything you think should be inside this update version.

thanks,
Weiming

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 27 Jan 2013 17:38:07 -0000

I'm ready with this version.

You need to post it.

Jamal, you need to determine that nothing changed here affects WG consensus.

Adrian

> -----Original Message-----
> From: Wang,Weiming [mailto:[email-masked]]
> Sent: 27 January 2013 14:38
> To: [email-masked]
> Cc: [email-masked]
> I think all the issues AD pointed has been addressed and a new v10 is ready to
> submit to IETF very soon. Pls feel free to show your comments if anything you
> think should be inside this update version.
> 
> thanks,
> Weiming
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 28 Jan 2013 06:57:38 -0500

> Jamal, you need to determine that nothing changed here affects WG consensus.

Text looks good.
The only one thing i'd ask for is the authors validate the changed xml
against the schema
before publishing.

Also, can you please post the xml as a separate file (as Evengelos
normally does)
so implementors dont have to extract it off the doc?

cheers,
jamal