Subject: RE: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS

From: "Edward Beili" <[email-masked]>
Date: Wed, 4 Aug 2004 05:55:44 +0300

Mike,
I agree that it would probably be a good idea to include the layering diagram into the efm-cu-mib.
 
The PCS in the EFMCu ports performs rate matching using flow control, while the MAC is running at 100Mbps. Since EFMCu interface speeds may vary depending on the copper conditions, configuration parameters and amount of PMEs aggregated, reporting the ifSpeed of the PCS as 100Mbps wouldn't really help. Reporting the ifSpeed of the PCS as the sum of the PME speeds is also incorrect as there's 64/65B encapsulation overhead with optional PAF overhead.
 
Regards,
-Edward 

	-----Original Message----- 
	From: C. M. Heard [mailto:[email-masked]] 
	Sent: Tue 8/3/2004 9:14 PM 
	To: Matt Squire 
	Cc: [email-masked]; [email-masked]; Edward Beili 
	Subject: Re: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS

	On Mon, 2 Aug 2004, Matt Squire wrote:
	> During the discussions today in the hubmib WG, the question
	> arose as to what should be the ifSpeed for 2BASE-TL & 10PASS-TS
	> interfaces.
	>
	> Traditionally, it seems the ifSpeed has been tied to the speed
	> of the MAC (e.g. 10Mbps, 100Mbps, etc.).  With 2BASE/10PASS, the
	> PHY may be running at a much lower speed than the 100Mbps MAC,
	> so its not particularly useful to the administrator to call all
	> of these interfaces 100M when the PHYs aren't there.
	>
	> Options for ifSpeed of 2BASE/10PASS seem to include the
	> following:
	>
	> 0) Use 100 Mbps (MAC speed).
	>
	> 1) Sum the physical date rates of PMEs in the aggregate (PHY
	> speed).
	>
	> 2) Use the rate of "goodput" on the PHYs (e.g. how much data can
	> ge thru).  This would ignore any overhead of the PHY (PAF,
	> 64/65) and overhead of the MAC (preamble, IPG).  This most
	> accurately reflects how much data can get thru.
	>
	> 3) Use the rate at the MAC/MII.  E.g. include preamble/IPG (even
	> though its not transmitted), but not PHY overhead (PAF, 64/65). 
	> This seems consistent with other PHYs, but is kinda weird in
	> that we're not actually transmitting preamble/ipg.
	>
	> There are probably other options too.  Thoughts/opinions?
	
	You might want to take a look at RFCs 3635 and 3637 to see what was
	done for 10GBASE-W.  In that case we used a layering model
	(specified via the ifStackTable) that had different ifSpeed values
	for different sublayers, and the speed at each sublayer corresponded
	to the rate at which that sublayer transmitted bit to and/or
	received bits from the sublayer below.  The ifSpeed values for the
	ifTable entries representing the SONET sublayers were specified in
	RFC 3637 Section 3.4, and the ifSpeed value for the ifEntry
	representing the PCS/RS/MAC/LLC sublayers was specified in RFC 3635
	Section 3.2.8.
	
	Hope this helps.
	
	Mike Heard
	WIS MIB editor
	
	P.S. It would probably be a Good Thing (tm) to have a stack table
	diagram in the next rev of draft-ietf-hubmib-efm-cu-mib

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Aug 2004 18:18:00 +0300

Yes!

Can we please consider this as a Last Call comment. 

(of course Mike, it would be great if you can have a look at the current set of Internet-Drafts now in WG Last Call and submit a full set comments).

Thanks and Regards,

Dan

---

From: "Edward Beili" <[email-masked]>
Date: Wed, 4 Aug 2004 21:17:52 +0300

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

	-----Original Message----- 
	From: [email-masked] on behalf of C. M. Heard 
	Sent: Wed 8/4/2004 7:25 PM 
	To: Hub Mib 
	Cc: 
	Subject: [Hubmib] IANA Maintained TC for MAU types

	On Tue, 3 Aug 2004, Romascanu, Dan (Dan) wrote:
	> The Ethernet interfaces and hub MIB WG (hubmib) met for one
	> session at the 60th IETF. The WG discussed the latest changes,
	> comments and open issues for the three chartered WG
	> Internet-Drafts related to the Ethernet First Mile (EFM)
	> technology.  The participants in the meeting recommended that
	> the MAU MIB be re-written to refer to a IANA-maintained Textual
	> Convention, which would ease the support for new MAUs in the
	> future, without requiring opening of the MAU MIB documents.
	
	I'd like to make a few comments about this idea.  The first point is
	that what needs to be extended in the MAU-MIB is not just a single
	BITS type definition but rather a BITS type definition that is lined
	up with a matched set of OBJECT-IDENTITY definitions.  The affected
	definitions in the MAU-MIB are these OBJECT-IDENTITY definitions:
	
	       dot3MauType
	           OBJECT IDENTIFIER ::= { snmpDot3MauMgt 4 }
	
	       dot3MauTypeAUI OBJECT-IDENTITY
	           STATUS      current
	           DESCRIPTION "no internal MAU, view from AUI"
	           REFERENCE   "[IEEE 802.3 Std.], Section 7"
	           ::= { dot3MauType 1 }
	
	       [ ... ]
	
	       dot3MauType10GigBaseSW OBJECT-IDENTITY
	           STATUS      current
	           DESCRIPTION "W fiber over 850 nm optics"
	           REFERENCE   "[IEEE 802.3 Std.], Section 52"
	           ::= { dot3MauType 40 }
	
	and the BITS type in the following OBJECT-TYPE definition:
	
	       ifMauTypeListBits OBJECT-TYPE
	           SYNTAX      BITS {
	               bOther(0),         -- other or unknown
	               bAUI(1),           -- AUI
	               [ ... ]
	               b10GbaseSW(40)     -- 10GBASE-SW
	           }
	           MAX-ACCESS  read-only
	           STATUS      current
	           DESCRIPTION "A value that uniquely identifies the set of
	                       possible IEEE 802.3 types that the MAU could be.
	                       If auto-negotiation is present on this MAU, this
	                       object will map to ifMauAutoNegCapabilityBits.
	
	                       Note that this MAU may be capable of operating
	                       as a MAU type that is beyond the scope of this
	                       MIB.  This is indicated by returning the
	                       bit value bOther in addition to any bit values
	                       for capabilities that are listed above."
	           ::= { ifMauEntry 13 }
	
	The IANA-maintained MIB module would need to contain the
	dot3MauType* OBJECT-IDENTITY definitions along with a TC (which
	might be called IANAifMauTypeListBits) that whose SYNTAX clause is
	what is presently in ifMauTypeListBits.  That, of course, is because
	these items have to remain in sync and so have to be maintained in
	parallel.  The IANA-maintained module would, of course, import the
	base OID descriptor dot3MauType from the MAU-MIB.
	
	One minor backward-compatibility issue is that migrating the
	OBJECT-IDENTITY definitions in this way could cause problems if any
	existing MIB modules have imported those descriptors from MAU-MIB.
	This could be addressed by keeping the existing list of dot3MauType*
	descriptors in the MAU-MIB as object identifier value assignments;
	while RFC 2578 does not permit two "registrations" of the same OID
	value, it does allow a descriptor to be associated with both a
	registration and an object identifier value assignment, providing
	both are associated with the same OBJECT IDENTIFIER value and
	semantics (cf. Section 3.6).
	
	Another issue that needs to be addressed is what rules apply to new
	MAU types.  My thinking is that this should be allowed ONLY by a
	Standards Action (as defined in RFC 2434) -- or at least IETF
	Consensus -- so that any prospective assignments are documented in
	an RFC.  Any document that proposes such an assignment should also
	be required to note any special properties of the MAU types that it
	defines -- for example, side effects on the ifStackTable such as are
	noted in RFC 3636 Section 3.4.1 for 10GBASE-W MAUs.
	
	Also to be noted is that the MAU-MIB itself will need some minor
	modifications beyond those discussed above, such as the DESCRIPTION
	clauses for rpMauType and ifMauType.   A good editor is needed to
	ferret all those things out.
	
	One final point:  in his reply to Dan Romascanu's comments on
	draft-ietf-hubmib-efm-epon-mib-01.txt, Lior Khermosh said:
	
	> Sorry for being not clear but my intention is that MAU type
	> objects in the MAU section should be added to the MAUMIBs as
	> with the efm-cu document. If it is not done there then the MAU
	> section in the efm-epon mib should contain them (as now).
	
	My position would be that we MUST modify the MAU-MIB -- either
	directly or by putting the MAU types into an IANA-maintained module
	-- to contain the new MAU type definitions.  It invites catastrophe
	(i.e., conflicting OID/bit position assignments) if the values
	assigned to MAU types are scattered over several documents.  I do
	agree that it is OK to split off MAU-specific stats counters and so
	on and put those in a separate module;  in fact there is no
	practical alternative to doing so if we don't want to change the
	MAU-MIB every time we add an MAU type that requires such things.
	
	Regards,
	
	Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 23 Aug 2004 09:59:42 -0700 (PDT)

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

Some comments on the ifSpeed, ifStackTable diagram, and MAU-MIB
usage issues that have already been discussed on this list to some
extent will appear in a forthcoming message.  In the meantime here
are some things that caught my eye when when looking at the docment
this weekend.

- On page 6 there is a typo:

   The SNMP Agent builds efmCuStackTable according to the information
   contained in the Clause 45 PME_Available_register (see [802.3ah]
   61.1.5.3 and 45.2.3.20).

The text should read:

   The SNMP Agent builds efmCuAvailableStackTable according to the
   information contained in the Clause 45 PME_Available_register
   (see [802.3ah] 61.1.5.3 and 45.2.3.20).

- On page 16, the DESCRIPTION clause of efmCuPAFAdminState says:

   PCS ports incapable of supporting PAF SHALL return a value of
   'disabled'. Attempts to 'enable' such ports SHALL be ignored.
________________________________________________________^^^^^^^

This will almost certainly raise a red flag during MIB Doctor review,
since the usual behaviour is to reject unacceptable values with an
SNMP error, not to ignore them.  I would recommend changing "ignored"
to "rejected".  There are other places where this is done, and they
should be changed, too.  I would also recommend that the compliance
statement include an OBJECT clause for this object with a WRITE-SYNTAX
clause specifying that values other than disabled need not be accepted.

- I see several places with Editor's Notes indicating that there are
open issues (e.g., text to be added, technical decisions to be made,
etc.)  These need to be closed off before we make a publication request.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 23 Aug 2004 14:18:30 -0700 (PDT)

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

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