RE: ifSpeed & 2BASE-TL/10PASS-TS

>>>>> On Wed, 4 Aug 2004, Edward Beili wrote:
EB> I agree that it would probably be a good idea to include the
EB> layering diagram into the efm-cu-mib.

>>>>> On Wed, 4 Aug 2004, Romascanu, Dan (Dan) wrote:
DR> Can we please consider this as a Last Call comment.
DR> 
DR> (of course Mike, it would be great if you can have a look at the
DR> current set of Internet-Drafts now in WG Last Call and submit a
DR> full set comments).

Unfortunately I don't have the time to do that but I will try to
address a couple of points that I previously agreed to comment on.  
Regarding the layering diagram, what I have inferred from the
document is something like the following;  please advise whether or
not it is correct.

  _______________________________   _
 |    LLC Layer                  |  |
 +-------------------------------+  |
 |    MAC Layer                  |  |
 +-------------------------------+  > 1 ifEntry
 |    Reconciliation Sublayer    |  |   ifType: ethernetCsmacd(6)
 +-------------------------------+  |
 |    Physical Coding Sublayer   |  |
 +-------+-------+-------+-------+  + N ifEntries
 | PME 1 | PME 2 |  ...  | PME N |  |   ifType: shdsl(169) for 2Base-TL
 +-------+-------+-------+-------+  -           vdsl(97) for 10Pass-TS

EB> The PCS in the EFMCu ports performs rate matching using flow
EB> control, while the MAC is running at 100Mbps. Since EFMCu
EB> interface speeds may vary depending on the copper conditions,
EB> configuration parameters and amount of PMEs aggregated,
EB> reporting the ifSpeed of the PCS as 100Mbps wouldn't really
EB> help. Reporting the ifSpeed of the PCS as the sum of the PME
EB> speeds is also incorrect as there's 64/65B encapsulation
EB> overhead with optional PAF overhead.

What we did for 10GBASE ethernetCsmacd(6) variants was to report the
"the current operational speed of the interface" (words from RFC
3635) _excluding_ 64B/66B overhead.  That comes out to 10000 Mb/sec
for 10GBASE-R (LAN) variants and 9294 Mb/sec for 10GBASE-W variants.  
I would say that either Matt Squire's option #2 or option #3 would
be consistent with that precedent:

>>>>> On Mon, 2 Aug 2004, Matt Squire wrote:
MS> 2) Use the rate of "goodput" on the PHYs (e.g. how much data can
MS> ge thru).  This would ignore any overhead of the PHY (PAF,
MS> 64/65) and overhead of the MAC (preamble, IPG).  This most
MS> accurately reflects how much data can get thru.
MS> 
MS> 3) Use the rate at the MAC/MII.  E.g. include preamble/IPG (even
MS> though its not transmitted), but not PHY overhead (PAF, 64/65). 
MS> This seems consistent with other PHYs, but is kinda weird in
MS> that we're not actually transmitting preamble/ipg.

In the 10GBASE cases the reported ifSpeed is the _effective_ rate at
which bits are transferred across the XGMII between the RS and PCS.
The "bits transferred" always includes the preamble and sfd.  It
includes all idle characters for 10GBASE-R PHYs, but for 10GBASE-W
PHYs it _omits_ the idle characters that are added or removed to
adapt the 10GB/s MAC data rate to the 9294 Mb/s "effectve" data rate
at the PCS/RS boundary.  In other words, it inclues the stuff that
actually gets transmitted over the physical medium, but it omits
stuff that is just used internally for adaptation but isn't sent
over the wire.

Based on that, I would be inclined to recommend option #2.  If the
EFMcu does not actually send preamble and IPG over the wire, then
those bits should probably not be included in the effective data rate.

>>>>> On Wed, 4 Aug 2004, Edward Beili wrote (in a different thread):
EB> While we are on the subject of MAU MIB I would like to share a
EB> little problem I'm having in EFM-CU-MIB:
EB> 
EB> As of today the IEEE P802.3af/D3.3 specifies oMAU being a
EB> sibling of the oPAF under a common oPHYEntity (see Figure 3-3 on
EB> page 692), which creates an impression that ifMauType is an
EB> attribute of the PHY (PCS) layer. Traditionally MAU is
EB> associated with PMA (see figure 4-1 on page 70 of 802.3-2002),
EB> which is actually a part of PME in EFMCu PHYs.
EB> 
EB> So, I see 2 main alternatives for EFMCu PHYs:
EB> 
EB> 1. Not to use MAU MIB at all and instead use appropriate ifType
EB> values (should be defined in IANAifType-MIB) for both PCS and
EB> PME ports. Note also that EFMCu ports don't use MAU
EB> auto-negotiation, media available, false carriers or jabber, so
EB> there really no reason for using MAU-MIB apart from the fact
EB> that all EtherLike interfaces are required to use it.
EB> 
EB> 2. Use ifMauType for PMEs only (theoretically PMEs can support a
EB> number of types so ifMauTypeList can be handy here). The PCS
EB> ifType would stay ethernetCsmacd and the real type would be
EB> returned in efmCuType and efmCuPortSide.

Note that every Ethernet-Like interface is required to use the
ifType = ethernetCsmacd(6), and up to now every ifEntry with
ifType = ethernetCsmacd(6) has been a consolidated representation
of (at least) the LLC, MAC, and PCS (sub)layers.  As a result,
management software has come to rely on the associated ifMauType
to distinguish between the various Ethernet flavors.  So, even
though you don't do autonegotiation and don't have any PCS status
conditions or statistics for the existing MAU MIB to report, you
still need an appropriate ifMauType to tell management software
to look in the EFM-CU-MIB for the desired information.

As for using the MAU-MIB for PMEs, that is not appropriate, since
these devices are not Ethernet-Like interfaces, and instantiation of
interface MAU objects is allowed only for Ethernet-Like interfaces,
as stated in the following excerpt from RFC 3636:

 It is REQUIRED that an agent implementing the interface-MAU related
 objects in this MIB will also fully comply with the dot3Compliance2
 MODULE-COMPLIANCE statement of the Ethernet-like Interfaces MIB,

So, if you use the layering model I depicted above, you will need
to instantiate the applicable interface MAU objects (in particular,
ifMauType) for each PCS, but you must not do so for the PMEs.  Note
that this would agree with what was done for 10GBASE-W interfaces.
For the 10GBASE-W interfaces we also used the counters from the
existing SONET-MIB (RFC 3592) for the WIS, which I suppose would be
a precedent in favor of using the existing VDSL and SHDSL MIB
modules for EFMcu.

Mike