RE: Augmenting MAU-MIB - was: RE: EFM MIB Internet-Draft s, WG Meetings

You are correct that auto-negotiation is not specifically described in
802.3ah for EFMCu.
The EFMCu ports use master/slave (-O/-R ports) configuration, the master
management entity can detect slave's capabilities via xDSL handshake during
link initialization and choose mutually acceptable capabilities for both
sides (via clause 45 registers).
Note that negotiation of -O/-R configuration per port is not described at
the moment, for example if both peer ports support -O and -R subtypes which
port accepts the role of master and which one the role of slave. I'm going
to raise a comment against the latest draft and require the use of
auto-negotiation for that purpose. The mechanism would be using xDSL
handshake of course and thus be different from clauses 22 and 37.

Regards,
-E.  




> -----Original Message-----
> From: Lior Khermosh [mailto:[email protected]]
> Sent: Wednesday, October 29, 2003 03:53 PM
> To: Edward Beili; 'C. M. Heard'; Dan Romascanu (E-mail)
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB 
> Internet-Draft s, WG Meetings
> 
> 
> Actually I think that L2 auto-neg is disabled for an EPON 
> interface. What
> level of negotiation exist for the copper interface? Can it 
> be distinguished
> in L2 from 10BaseT for instance or is the negotiation only to 
> define between
> VDSL modes of operation.
> 
> 
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Edward Beili
> Sent: Wednesday, October 29, 2003 3:10 PM
> To: 'C. M. Heard'; Dan Romascanu (E-mail)
> Cc: '[email protected]'; Lior Khermosh (E-mail)
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> Internet-Draft s, WG Meetings
> 
> 
> Mike,
> 
> The new copper interfaces can be administratively controlled and
> auto-negotiated, so I guess a new RFC should be issued to 
> replace RFC 3636.
> I would suspect that new EPON interfaces can be 
> auto-negotiated as well.
> 
> Dan,
> Can we ask to open a new version of MAU-MIB?
> 
> Regards,
> -Edward
> 
> > -----Original Message-----
> > From: C. M. Heard [mailto:[email protected]]
> > Sent: Wednesday, October 29, 2003 07:51 AM
> > To: '[email protected] '
> > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> > Internet-Draft s, WG Meetings
> >
> >
> > On Thu, 23 Oct 2003, Edward Beili wrote:
> > > We would also need to augment current MAU-MIB with new
> > > dot3MauType instances defined for EPON and Copper interfaces. Do
> > > we have to open a new version of MAU-MIB (and who does it) or
> > > there's another way of doing it?
> >
> > and on Tue, 28 Oct 2003, Edward Beili wrote:
> > > Going back to my original question: what is the procedure for
> > > updating the MAU-MIB?
> >
> > What actually needs to be done is to generate some new
> > OBJECT-IDENTITY definitions to specify OIDs that can figure as
> > values of rpMauType or ifMauType and ifMauDefaultType.  I think that
> > the question is whether it is feasible to put the new
> > OBJECT-IDENTITY definitions in another MIB module or whether they
> > need to go into the MAU-MIB.  Here is my take on that question.
> >
> > If the new MAU types could be potentially auto-negotiated, then they
> > must have corresponding bit positions in ifMauTypeListBits.  In that
> > case the right thing to do would be to register the new values under
> > dot3MauType (as has been done for other "standard" MAU types) and to
> > add corresponding bit positions to ifMauDefaultType.  This would
> > require that the MAU-MIB be revised and that a new RFC be issued to
> > replace RFC 3636.  The WG group has the authority to do this if it's
> > deemed necessary.  I don't believe that small modifications like
> > this would necessarily affect "time in grade" for the purposes of
> > standards track advancement since no new objects would be added.
> >
> > On the other hand, if the new MAU types could NOT be auto-negotiated
> > but could only be set statically or reported, then there would be no
> > need to add bit positions to ifMauDefaultType, and the new OID
> > values could in principle be registered anywhere convenient.  If
> > they were registered under some top-level OID other than dot3MauType
> > then there would be no need to revise the MAU-MIB.  This is how
> > proprietary MAU types are handled, BTW.
> >
> > Mike
> >
> >
> > _______________________________________________
> > Hubmib mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/hubmib
> >
> 
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>