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