RE: RE: [Fwd: RE: commentsondraft-ietf-hubmib-efm-cu-mib-02.txt]

Dan - 

 

I just uploaded -03 of the EFM OAM MIB.

 

- Matt

 

  _____  

From: Romascanu, Dan (Dan) [mailto:[email protected]] 
Sent: Wednesday, March 23, 2005 12:18 PM
To: Matt Squire; Edward Beili
Cc: [email protected]
Subject: RE: [Hubmib] RE: [Fwd: RE:
commentsondraft-ietf-hubmib-efm-cu-mib-02.txt]

 

May I please ask the editors to hurry with the update process and submit
the updated Internet-Drafts?

 

We are almost two weeks late relative to the schedules, and only one of
the four expected Internet-Drafts was submitted. 

 

Of course, this should not be at the expense of quality :-) We want this
round to be the last in the WG. 

Thanks and Regards,

Dan

	-----Original Message-----
	From: [email protected] [mailto:[email protected]]On
Behalf Of Matt Squire
	Sent: 23 March, 2005 7:02 PM
	To: Edward Beili
	Cc: [email protected]
	Subject: RE: [Hubmib] RE: [Fwd: RE:
commentsondraft-ietf-hubmib-efm-cu-mib-02.txt]

	Ed - 

	 

	Sorry for the delay.  I'm ok with all your responses.  Thanks.

	 

	- Matt

	 

	
  _____  


	From: [email protected] [mailto:[email protected]]
On Behalf Of Edward Beili
	Sent: Monday, March 14, 2005 9:28 PM
	To: Matt Squire
	Cc: [email protected]
	Subject: [Hubmib] RE: [Fwd: RE: comments
ondraft-ietf-hubmib-efm-cu-mib-02.txt]

	 

	 

	>-----Original Message-----
	>From:  Matt Squire [mailto:[email protected]]
	>Sent:  Thu 3/3/2005 9:42 PM
	>To:    Edward Beili
	>Cc:    [email protected]
	>Subject:       RE: [Fwd: RE: comments on
draft-ietf-hubmib-efm-cu-mib-02.txt]
	>
	>>P17, efmCuPAFDiscoveryCode.  Why is this read-write?  Seems
like this
	>>should be generated by the system rather than provisioned by
	>>management.  E.g. the system can select a unique code based on
MAC
	>>addresses, OUIs, etc.  Setting this via management seems more
	>>problematic than beneficial.  Its probably nice as read-only
for
	>>troubleshooting reasons, but I don't get the r/w.
	>
	>[EB] Your arguments are valid and initially I made this object
	>read-only. However the standard does not specify how the
discovery
	>code is selected or which body would govern the code
assignment. So it
	>is possible that two -O ports from different manufacturers
would have
	>the same discovery code, thus I left the write capability to
deal with
	>such cases. As an alternative we could choose a specific
selection
	>method (say the MAC address of the port), specify it in the MIB
and
	>make the efmCuPAFDiscoveryCode read-only.
	>
	><MBS>
	>Got it.  Sounds like something we should have specified in the
	>standard.  Is it possible the definition got punted into
G.994.1?
	>
	>I remember it talking about using a unique MAC address at one
point,
	>but I can't find it in there now either.
	></MBS>
	
	[EB] We talked about it at one point in the IEEE, if I remember
	correctly there was some opposition from a certain equipment
vendor - may be
	they wanted to save a dollar on the MAC - don't remember the
exact
	reasoning right now. In any case no notion of MAC has made it
into the
	802.3ah or the relevant ITU-T standards.
	I suggest we leave efmCuPAFDiscoveryCode read-write and
recommend
	using port's MAC address as the default value in the RFC.
	
	>>P17, efmCuAdminProfile. Why do we say "current operating
Subtype of
	>>the PCS" instead of just "the subtype of the PCS"?.  Can that
subtype
	>>change?  Also, given we're having profiles on the EFMCu and
PME level,
	>>would it be better to have the PME level override the EFMCu
level?  If
	>>we switched precedence order (PME wins over EFMCu), we don't
lose any
	>>management function, but we allow the manager to set a default
for all
	>>PMEs with the ability to override speicfic PMEs with something
else.
	>>So we get more function, and don't lose anything.
	>
	>[EB] The subtype of the PCS can not be changed by an admin
command. It
	>reflects the common subtype of the connected PMEs. The system
vendor
	>may decide to fix the PMEs subtype (this would be indicated by
the
	>single value of efmCuPmeSubTypesSupported and obviously the
resulting
	>system can only be a CO or a CPE) or make it manageable, in
which case
	>the administrator would change the PMEs subtype to make the
resulting
	>aggregated port to be of a specific subtype.
	>
	><MBS>
	>So you're trying to allow for a system where one can configure
a PME
	>to be either 10P or 2B?  Is that realistic?
	></MBS>
	
	[EB] No, it is not very realistic today. However the standard
allows this
	option to be implemented by the chip vendor. Besides I do know
at
	least one chip vendor providing DMT and Baseband DSL support on
the
	same chip. So I suggest leaving it as it is today.
	
	>As for the precedence order between PME and PCS, I would leave
	>the PCS winning over the PMEs. Usually the user would want the
	>same profile on all PMEs, mostly due to the spectral
restrictions that
	>all PMEs must obey. The administrator can still set the PMEs
	>individually by setting the value of efmCuAdminProfile to empty
list,
	>so there's no functionality loss. When there is a need to
change the
	>profile of the aggregated link it is easier to change just one
	>parameter (efmCuAdminProfile) and not to worry about checking
(and
	>possibly re-writing) the individual efmCuPmeAdminProfile values
for
	>each PME in the link.
	>
	><MBS>
	>I'm more familiar with models such that when there is a set of
things
	>to manage (any things) that may require similar provisioning,
you
	>allow easy management of the group via some configurable group
	>behavior, and then allow exceptions on individual elements in
that
	>group.  The current description is exactly the opposite.
	>
	>So I still disagree with the logic expressed in the MIB.  If
I'm alone
	>in thinking that way, then I'll go quiet, but it just strikes
me as
	>inverted.
	></MBS>
	
	[EB] Judging by the amount of comments I received on this
subject -
	you are alone:) Actually it does matter that much, it is just a
	convention, so I would agree with you for a change:
	I would specify that PME wins over the PCS. I would also add the
	default profile for the PME as null, so when the user
initializes the
	PCS profile for the 1st time after system's init, he/she would
not
	have to worry about checking each individual PME profile for
overrides.
	
	>>P8, 3.1.5.  On ifAdminStatus for the PAF, we say setting it to
"up"
	>>re-initializes all PMEs associated with it.  Does setting the
	>>ifAdminStatus of the PCS to "down" take down all PMEs as well,
or
	>>does it just stop aggregation from occurring?  Does the
ifAdminStatus
	>>of the PMEs automatically change with that of the EFMCu port?
	>>There's still some more clarity needed here.  I guess I don't
really
	>>care which way it ends up, but we need to say one way or the
other.
	>
	>[EB] Good point. I suggest the following clarification:
	>
	>Changing the ifAdminStatus for a PCS from "down" to "up"
initializes the PCS
	>and all PMEs connected to it, unconditionally setting the value
of
	>ifAdminStatus of all connected PMEs to "up".
	>
	>Changing the ifAdminStatus for a PCS from "up" to "down" shuts
down
	>the PCS and all subtending PMEs, unconditionally setting the
value of
	>ifAdminStatus of all connected PMEs to "down".
	>
	>Changing the ifAdminStatus for a PME from "down" to "up"
initializes
	>the PME regardless the value of ifAdminStatus for the PCS
connected to
	>that PME. Note that EFMCu PME initialization is a lengthy
process
	>which may succeed or fail (e.g. if initialization parameters
cannot be
	>achieved due to the copper characteristics). The ifOperStatus
for the
	>PME SHALL remain "down" for the duration of initialization.
	>>> EdNote: anoter alternative is to make ifOperStatus to be
"dormant"
	>during initialization, however the definition of "dormant" in
the
	>IF-MIB is "waiting for an external action" and initialization
is
	>really a self-sufficient process which doesn't require any
external
	>action for completion. <<
	>At the end of a successful initialization, the ifOperStatus
SHALL
	>change to "up". It SHALL remain "down" if the initialization
fails. The
	>efmCuPmeOperStatus provides additional information on the
operational
	>status of the PME, indicating if the PME is down and there is
no
	>handshake tones ("downNotReady"), the PME is down and the
handshake
	>tones are detected ("downReady"), the PME is initializing
("init") and
	>the PME is ready to pass operational traffic ("up").
	>Note that no operational traffic can pass via the PME if the
	>aggregating PCS is administratively "down".
	>
	>Changing the ifAdminStatus for a PME from "up" to "down" shuts
down
	>the PME link, regardless the value of ifAdminStatus for the PCS
	>connected to that PME. The ifOperStatus for the PME SHALL
change to
	>"down", with efmCuPmeOperStatus indicating "downReady" or
	>"downNotReady" depending on the handshake detection form the
peer PME.
	>
	><MBS>
	>The general philosophy is ok with me.  I would not be in favor
of
	>using 'dormant' as the status during initialization, it doesn't
seem
	>to fit.
	
	[EB] So, the ifOperStatus of the PME would remain "down" during
initialization.
	
	>As a nit, I'm also not sure the sentence "Note that no
operational
	>traffic can pass via the PME if the aggregating PCS is
	>administratively "down". " is completely accurate.  For
example, if
	>you had
	>
	>         A                      B
	>      PCS down                PCS up
	>      PME up                  PME up
	>Then operatational traffic can pass from B thru the PME but be
	>discarded at A's disabled PCS.  I guess I'm not sure where the
"pass"
	>in the sentence applies - data can pass thru a PME in one
direction,
	>it just can't enter from a PCS into a PME.
	></MBS>
	
	[EB] It is an interesting example. I believe that in a
conventional
	10/100BaseT link when one end goes down, the other one goes
	operationally down as well. So if we are to imitate that
behavior
	(which is how one would usually discover that the peer PCS has
gone
	down) the original wording is correct. So I suggest leaving it
as it
	is adding some explanation about the behavior described above. 
	
	>>P21, efmCuPeerPAFSupported.  Seems like it might be worthwhile
to have
	>>a third value (unknown) given thats whats in 30.11.1.1.9.
Makes the
	>>mapping easier:)
	>
	>[EB] I wanted it to resemble the boolean syntax of
efmCuPAFSupported,
	>also Clause 45 Remote PAF Supported bit has only 2 values.
Supporting the
	>unknown value would require some intelligence from the SNMP
agent.
	>>> EdNote: I'd like to get more opinions here <<
	><MBS>
	>I would argue that its better to map to whats in C30 than whats
in
	>C45.  One of the reasons for C30 is to put a more intelligent
layer
	>between the registers and the management entity.
	></MBS>
	
	[EB] Ok, I'll add the unknown value to efmCuPeerPAFSupported,
adding
	an additional textual convention:
	    TruthValueOrUnknown ::= TEXTUAL-CONVENTION
	     DISPLAY-HINT "d"
	     STATUS       current
	     DESCRIPTION
	       "This textual convention is an extension of the
TruthValue
	       convention. The latter defines a boolean value with
	       possible values of true(1) and false(2). This
	       extension permits the additional value of unknown(0),
which
	       can be returned as a result of GET operation, when an
exact
	       true or false value of the object cannot be determined."
	     SYNTAX       INTEGER { unknown(0), true(1), false(2) }
	
	>>P29, PME Notifications.  Many of the notifications
(DeviceFault,
	>>ConfigInitFailure, ProtocolInitFailure) seem like they could
be
	>>handled by one notification- e.g. there was a failure and a
reason
	>>for the failure.  You're including the FltStatus anyway - do
we need
	>>multiple notifications?  I know in some you include more info
(for
	>>example, the profile index), but does getting an integer index
into
	>>a profile table help the notification receiver to know what
	>>happened?  Also, are there any rules/guidelines on using these
with
	>>the standard linkDown ifTable notification?  Can/should
someone send
	>>both, one or the other, does it matter, etc.?
	>
	>[EB] I've copied most of the notifications from the SHDSL
	>MIB. I guess I could group together ConfigInitFailure and
	>ProtocolInitFailure, since they both happen during
initialization
	>phase, DeviceFault is a bit different as it can happen anytime
	>(e.g. as a result of a periodic test). On the other hand IF-MIB
put 2
	>different traps for linkUp and linkDown events (these could
certainly
	>be served by the same notification), so I'm not sure what is
the rules
	>here.
	>>> EdNote: I'd like to get more opinions here <<
	><MBS>
	>Yea, I dont know that there's a best or standard way.  I'm ok
with
	>whats there, I'd also be ok if we wanted to condense the list.
Since
	>you're including the FltStatus anyway, there's some information
there
	>to differentiate different types of faults.
	></MBS>
	
	[EB] So I'm keeping the current text as it is.
	
	>>P44, EfmCu2BConfProfileEntry.  The definitions here allow a
	>>completely rate adaptive profile (set data rate to 0), but not
a
	>>restricted data rate profile (e.g. between 2 and 4 Mbps).
Supporting
	>>min/max rates would be good.
	>
	>[EB] efmCuAdminProfile is a list of up to 6 pointers to profile
entries, which
	>allows you to specify up to 6 different possible rates.
	>Current clause 45 registers do not allow specification of a
restricted
	>data profile, that is why I didn't do it. Besides EFM puts a
	>limitation of 1:4 ratio between the fastest and the slowest PME
in the
	>aggregation group, so you would always have a min rate in the
rate
	>adaptive profile, based on the highest attainable rate, which
is in
	>turn limited by the region, power and constellation.
	>In general I tried not to put in the MIB anything that could
not be
	>supported by clause 45 registers or clause 30 objects.
	>
	><MBS>
	>If I look at C45.2.1.43 and 45.2.1.57, one can setup minimum
and
	>maximum data ranges, as well as the step function available
between
	>them.  Am I missing something?   There seems to be a lot of
	>flexibility there.
	></MBS>
	
	[EB] Personally I don't see the point in limiting the min. modem
rate.
	This issue aside, there was some general consensus at the EFM
group at
	the time, that most operators would prefer to choose between
	standard profiles (up to 6), so clause 45 registers were
constructed in such a
	way to provide 6 profiles to choose from.
	While I could mimic these registers behavior in the MIB,
providing
	both list of profiles and (min,max,step) configuration seems
like an
	overkill.
	I suggest leaving it as it is now.
	
	>>P4, 3.1.1.  There are a couple definitions of the ifSpeed of
the PCS
	>> a) ifSpeed is "rate across the MII" (in 3.1.5)
	>> b) ifSpeed is "sum of the current operating data rates of all
modems
	>>in the aggregation group without the 64/65B encapsulation
overhead
	>>and PAF overhead but accounting for the interframe gap"
	>>
	>>I'd prefer we just go with the first one consistently.  If you
want
	>>to state somewhere what goes across the MII, thats fine, but
it seems
	>>like there are two definitions laying out there.
	>
	>[EB] I view both definitions a) and b) as equivalent. I agree
that
	>since there is no clear formula defined it is hard to compute
the
	>ifSpeed value (it would depend on the frame size, IFG, fragment
size
	>etc.).
	>In the end I guess the equipment would report some empirical
function of
	>the PMEs rates (say 95% of the sum of the rates), as long as
there is
	>no frame loss in the configuration with the test sets.
	><MBS>
	>I agree with the equivalence, I just wasnt sure its an obvious
	>equivalence.  Since both seemed to be used as definitions
	>(e.g. "ifSpeed is XYZ" and "ifSpeed is ABC"), I thought it
might cause
	>confusion.  Not a big deal either way.
	></MBS>
	
	[EB] I've removed "rate across MII" definition, as it is much
harder
	to understand than the other definition.
	
	Regards,
	-E.

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