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

Bob,
There's a lot of sense in your proposal, in fact I was thinking along the
same lines a while ago. The connection capability tables could benefit other
areas as well as the discovery stuff. And of course it is needed in
G.Bond/M2DSL MIBs. The only issue I have with this is the time frame.
I would like to have the EFM-CU-MIB approved around the same time as the
802.3ah is approved (summer 2004). I'm not sure it is possible if we start
splitting the stuff now. That was also my problem with using your excellent
VDSL and SHDSL MIBs - SHDSL.bis is not even started, besides there are some
things (e.g. rate settings) that are done differently in EFM and SHDSL.bis.
That was also the general feeling in the HUBMIB group and the EFM that it is
better to define everything in a single MIB.

So, if splitting the MIBs can be done in time, then I would go for it.
Otherwise I would like to finish the EFM-CU-MIB and worry about general
things later.

I'm CC:'ing the HUBMIB group, for the benefit of those not subscribed to
ADSLMIB, as I would like to hear their opinion as well.

Regards,
-Edward


-----Original Message-----
From: Bob Ray
To: Edward Beili
Cc: adslmib mail list
Sent: 13/03/04 00:34
Subject: RE: [Adslmib] 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