RE: MIBs for ITU-T G.Bond and T1E1 M2DSL projects

On Thu, 2004-03-04 at 14:11, Edward Beili wrote:
> You are right of course about the bonding stuff. I would like to have the
> common MIB to manage the aggregation assignment and retrieval for all of
> them. Note that ifStack describes and configures actual cross-connect
> between the bonded group (upper layer) and individual lines (lower layer).
> Another table is needed to describe cross-connect capability, e.g. which
> lines can be connected to which groups, in case there are multiple groups.
> Take a look at the EFM-CU-MIB:
> http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt
> 
> Regards,
> -Edward
>   

Hi.  I've been reading your draft.  Really, I have!

Being a co-author of the HDSL2/SDHSL MIB and of the VDSL MIB, I am
disheartened by your discarding of them.  But, I'll get over it!
As for G.SHDSL.bis, we're addressing that...

I wonder why EFM is redefining and duplicating all these objects, 
but don't have the clarity of vision perhaps to understand.  

I also wonder if many EFM vendors would end up implementing both
sets of objects for a given modem (IETF model and EFM model) which
would result in an increase in effort instead of a reduction
in effort (you claim the EFM model has fewer objects to support).
In any case, that's for the EFM guys to decide, I suppose.

Ok.  With THAT over with, the non-duplicated meat of your draft
seems to be concerned with the "available" cross connects, which
seems interesting.  If I read your efmCuAvailableStackTable correctly,
what you are stating is that the table contains a list of possible 
connections.

RFC2863: For example, when the sub-layer with ifIndex value x runs 
	 over the sub-layer with ifIndex value y, then this table
         contains:

              ifStackStatus.x.y=active

RFC2864: For example, when the sub-layer with ifIndex value x runs
         underneath the sub-layer with ifIndex value y, then this
         table contains:

              ifInvStackStatus.x.y=active

You propose a new table that will report if x and y *CAN* be connected,
which makes a lot of sense.

You:	 For example, when the PCS port with ifIndex value x can be
         connected to run on top of the PMI with ifIndex value y,
         then this table contains:

               efcCuAvailableStackTable.x.y=active

I think a draft which contains just such a table (and of course the
inverse ala ifInvStackTable) would be of use in many places, not just
in the EFM world.  For example, in broadcast video switches.  Which
leads to the suggestion that perhaps two drafts (an available draft
and an InvAvailable draft) are in order.  I think great utility
outside of EFM/DSL could be derived from such work - as long as it's
interface neutral (i.e. no dsl/efm/ethernet stuff).

However, I don't think the adslmib working group would be the right
place for it.  That is, the Interfaces MIB working group would seem
to be the best place for it (is that group still formed?).  I wonder
if the hubmib group is the closest thing still running to that group.
Bert?  Mike?

In short, then, my suggestions are:

1.  EFM consider using existing MIBS (with the assumption that we
    drones in the IETF get g.shdsl.bis support going), and that
2.  you create two drafts, somewhere, to implement your excellent idea 
    of "can connect" and "inverse can connect" tables.

Bob Ray