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

From: Bob Ray <[email-masked]>
Date: Thu, 04 Mar 2004 13:49:50 -0600

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: Edward Beili <[email-masked]>
Date: Thu, 4 Mar 2004 21:26:51 +0200

Bob,

I see 2 alternatives:
We could however specify a common MIB with an overview of the G.Bond/M2DSL
and common stuff like Discovery (even though it is not specified in the ATM
track) and Aggregation, similar to the EFM-CU-MIB. And then each track will
have it's own MIB for the specific stuff, e.g. FEC configuration and Service
configuration for the TDIM etc.
An alternative would be to include everything in a single MIB and use
compliancy statements to specify groups specific to each method. The
resulting MIB would be huge and hard to navigate.

My personal preference is the 1st option, i.e. common MIB and 3 additional
MIBs per each method.

Regards,
-Edward

> -----Original Message-----
> From: Bob Ray [mailto:[email-masked]]
> Sent: Thursday, March 04, 2004 05:18 PM
> To: Edward Beili; adslmib mail list
> Cc: [email-masked]'
> Subject: Re: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects
> 
> 
> On Tue, 2004-03-02 at 11:54, Edward Beili wrote:
> > Dear members of ADSLMIB group,
> > 
> > I would like to start working on the MIBs for the ITU-T G.Bond
> > and T1E1 M2DSL projects (please read my original letter at the
> > bottom of this mail for a short description of these projects).
> >  
> > Dan Romascanu has suggested your working group as the most 
> > fitting to host such MIBs. I would appreciate your opinion on 
> > that matter. At the very least please indicate if you would be
> > interested to participate in the work on those MIBs. 
> >  
> > Regards,
> > -Edward Beili
> > Actelis Networks
> >  
> 
> FWIW, I agree.  I keep looking at g.shdsl.bis and it is obvious
> what is going on; very much related.  
> 
> 	2 wires -> 4 wires -> 8 wires -> ????
> 
> I wonder if, instead of having three mibs, you/we instead devise 
> a generic mapping scheme; a level of indirection.  Do you have an
> initial feel if such an approach would work?  Does something based
> upon the ifStack approach work here?
> 
> Bob Ray
> 
>