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

From: "Michael Sneed" <[email-masked]>
Date: Thu, 04 Mar 2004 15:44:32 -0500

Before we go too far down this path, I think I should make it clear that we 
are trying  first of all  to answer the question as to whether this work is 
appropriate for this WG, or, more precisely, whether this WG should charter 
the work.

Of course, in order to do that we have to have some idea as to what work 
would need to be done, and Bob's discussion is on track in that arena.  I 
would personally like to understand more about what is being proposed, and 
what MIBs might be necessary.

But we should keep in mind that this is not currently part of our charter.  
So designing MIBs is a bit out of scope.

>From: Bob Ray <[email-masked]>
>Reply-To: [email-masked]
>To: Edward Beili <[email-masked]>
>CC: adslmib mail list <[email-masked]>
>Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects
>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

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/

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

---

From: Edward Beili <[email-masked]>
Date: Sat, 13 Mar 2004 01:34:46 +0200

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
> -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

---

From: Edward Beili <[email-masked]>
Date: Sat, 13 Mar 2004 01:44:55 +0200

Back to  the original question.

An example of what the TDIM MIB could include:
- Pair Discovery
- Aggregation Group provisioning
- Service Provisioning
- FEC/Interleaving provisioning
- Group Performance (error counters) and Pair Status

The system implementing G.Bond protocol would also use an appropriate xDSL
MIB corresponding to the underlying modem technology.

The latest ITU-T G.Bond drafts can be found on the ITU site:
http://ties.itu.ch/u/tsg15/sg15/wp1/q4/04-03-Millbrae/MC-040R1.zip - TDIM
http://ties.itu.ch/u/tsg15/sg15/wp1/q4/04-03-Millbrae/MC-132R1.doc - ATM
http://ties.itu.ch/u/tsg15/sg15/wp1/q4/04-03-Millbrae/MC-049R1.doc -
Ethernet
(if you are not an ITU member write to me which drafts you are interested in
and I would send it to you).

Regards,
-Edward

-----Original Message-----
From: Michael Sneed
To: [email-masked]; Edward Beili
Cc: [email-masked]
Sent: 04/03/04 22:44
Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects

Before we go too far down this path, I think I should make it clear that
we 
are trying  first of all  to answer the question as to whether this work
is 
appropriate for this WG, or, more precisely, whether this WG should
charter 
the work.

would need to be done, and Bob's discussion is on track in that arena.
I 
would personally like to understand more about what is being proposed,
and 
what MIBs might be necessary.

But we should keep in mind that this is not currently part of our
charter.  
So designing MIBs is a bit out of scope.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/