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>


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

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>

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


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


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

As for the concurrent linkUp/linkDown notifications - most of the
notifications defined in the MIB are independent from those link
notifications, i.e. ConfigInitFailure and ProtocolInitFailure happen
during initialization when link continues to be down, DeviceFault if
happened during normal work would probably be preceded by linkDown,
LineAtnCrossing and SnrMgnCrossing would not cause any linkDown events
by themselves, efmCuLowBandwidth would probably be preceded by a linkDown in
one or more PMEs, so once again - they are independent and I'm not
sure this fact should be explicitly stated in the MIB.
<MBS>
I see the reasoning now.  Thanks. 
</MBS>

>P39, efmCuPmeFltStatus.  Should this be zero'd when the link is up or
>initializing (there's no current faults in these oper states).  Or is
>this intended to hold the last fault?

[EB] You are right, it is not clear. My intention was as follows:
 - All indications hold the last fault
 - lossOfFraming, configInitFailure, protocolInitFailure - cleared by the PME init & device restart.
 - deviceFault - cleared by successful diagnostics/test & device restart
 - snrMgnDefect, lineAtnDefect - cleared by snrMgn/lineAtn returning
 to norm (above threshold), PME init, device restart
>> EdNote: Should it all be also cleared by setting the PME
administratively Down? <<
 
<MBS> 
That helps a lot.  
</MBS>


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

>P4, 3.1.1.  What is the "configured bit-rate for a pre-activated
>modem"?  What is the ifSpeed of a PME when it is in a rate adaptive
>mode? 

[EB] What I had in mind was to show max data rate specified by the
profile as ifSpeed for a PME during initialization. I now think it is
better to return 0 during initialization or when the link is down.
<MBS>
I agree that 0 would probably be better.  
</MBS>

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


>P29-30, Notifications.  Some of the defined notifications are events,
>others are threshold crossing.  For the threshold crossing, is the
>notification to be generated when the threshold is crossed in each
>direction, only when its exceeded, etc.?  E.g. there are
>linkUp/linkDown notifications defined in other MIBs for when things
>go up and down, its not clear if the threshold notifications should
>be sent on clear as well.  I think they should be, but the text
>doesn't really indicate one way or another.

[EB] Actually I just copied it from the SHDSL MIB:).
My understanding of the current text (as well as the one in SHDSL and
VDSL MIBs) is that the notification is not sent on clear, but
only when the threshold is exceeded. However it does make sense to
provide a notification on clear as well, so I've changed the text accordingly.
 
<MBS> 
That'll help.  
</MBS>


>P42, status table. In the efmCuPmeStatusTable, it's not clear what
>should be returned for some of the objects when the link is down or
>initializing.  Some of the objects have text (efmCuPmeOperProfile)
>while others don't (efmCuPmeSnrMargin, etc.).  Should probably
>consistently say what to return when the PME is down.

[EB] You are right. I suggest adding an additional out of range
value of 65535 (similar to efmCuPme10PElectricalLength, meaning that
the data is unavailable) for efmCuPmeSnrMargin,
efmCuPmePeerSnrMargin, efmCuPmeSnrMargin, efmCuPmePeerSnrMargin when
the PME is down or initializing and the value of 0 for
efmCuPmeTCCodingErrors when the PME is down or initializing.
 
<MBS>
Works for me.
</MBS>

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