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

Edward,

	I agree with Bob. There is a lot of duplication work going on.
 The hubmib WG charter clearly states and I quote: 

"The working group will also take
into consideration management objects defined by other
Working Groups in the IETF (ADSL MIB for example), or other
standard bodies (G.983.2), will avoid work duplication,
and describe the relationship with these specifications."

	 
 In my humble opinion, all of us ADSLMIB WG and HUBMIB WG need to work out
and define the relationship
 between the two MIBS and how best they be implemented together. It would be
a real shame to produce a MIB that duplicates and/or does not co-exist with
the VDSL and SHDSL MIBs which are already completed and implemented in
equipment. I don't think that the "time frame" issue is a "real" issue and
I'm sure that if both Working Groups make 
an effort this issue can be sorted out quickly.



	Regards,

	Menachem Dodge.

	Infineon Technologies Savan.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Edward Beili
Sent: Saturday, March 13, 2004 1:35 AM
To: 'Bob Ray '
Cc: 'adslmib mail list '; 'Romascanu, Dan (Dan) '; '[email protected]'
Subject: RE: [Adslmib] 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



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