Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects

From: Edward Beili <[email-masked]>
Date: Thu, 4 Mar 2004 22:11:04 +0200

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

> -----Original Message-----
> From: Bob Ray [mailto:[email-masked]]
> Sent: Thursday, March 04, 2004 09:50 PM
> To: Edward Beili
> Cc: adslmib mail list
> Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects
> 
> 
> Alternative One would be an approach similar to what has
> been done with VDSL.  That is, breaking the line code
> specific functionality out into separate documents.
> 
> My suggestion was merely tossing out the notion of
> introducing a stratifying structure where a draft would
> allow the reuse of existing efforts (i.e. dsl, ethernet,
> t1/e1, etc.) by specifying that a given "line" is actually 
> composed of subordinate lines of a given ifType.
> 
> For example, say the iana defines a new ifType bonded(xxx)
> (http://www.iana.org/assignments/ianaiftype-mib), and you
> define a MIB to manage a bonded line.  
> 
> Using an ifStack approach (see interfaces MIB) and RFC2127
> (http://www.ietf.org/rfc/rfc2127.txt), it would appear that 
> a bonded line could be defined in a single document without 
> having multiple documents defined for the well-known (?) 
> lower layers.
> 
> For example, a fractional T1 (or E1) line can be considered a 
> collection of bonded DS0s, no?  Representing this fractional
> T1 line via the ifStack table should be straightforward (and
> is done to some degree in RFC2127).
> 
> Please note that the above is borne aloft solely on the soiled
> wings of my ignorance and curiosity.
> 
> Regards,
> Bob Ray
> 
> 

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

---

From: Bob Ray <[email-masked]>
Date: Fri, 12 Mar 2004 16:34:03 -0600

> http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt

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