Subject: RE: [Hubmib] New things for the EFM-CU-MIB

From: "Edward Beili" <[email-masked]>
Date: Mon, 19 Feb 2007 14:10:26 +0200

Dear Hubmib group members,

I would like to hear your opinion on the proposed additions to the EFM-CU-MIB specified in my original mail below.

Regards,
-E.

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, December 11, 2006 16:22
> To: Edward Beili; [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: [Hubmib] New things for the EFM-CU-MIB
> 
> I believe that the WG should focus on completing the current 
> charter before discussing about any new work 'stemming from 
> ... latest RFPs', otherwise it risks to run forever trying to
> catch with the permanently moving target of the Ethernet technology.  
> 
> Dan
> 
> -----Original Message-----
> From: Matt Squire [mailto:[email-masked]] 
> Sent: Friday, December 08, 2006 2:53
> To: Edward Beili; [email-masked]
> Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail)
> Subject: RE: [Hubmib] New things for the EFM-CU-MIB
> 
> Hi Ed - 
> 
> The second two seem useful.  The first one doesn't seem that 
> useful as it is easily derived from other entries.  In 
> general, I'm not a big fan of adding 2nd level data (e.g. 
> stuff derived from other stuff).  
> 
> My 2 cents. 
> 
> - Matt  
> 
> > -----Original Message-----
> > From: Edward Beili [mailto:[email-masked]]
> > Sent: Friday, December 08, 2006 12:41 AM
> > To: [email-masked]
> > Cc: Wijnen, Bert (Bert); Romascanu, Dan (Dan)
> > Subject: [Hubmib] New things for the EFM-CU-MIB
> > 
> > Hi,
> > 
> > I would like to propose a few minor modifications to the EFM-CU-MIB, 
> > to provide support for some carrier requirements for the Ethernet over 
> > copper, stemming from some latest RFPs.
> > 
> > 1. Add a new leaf to efmCuPortStatusTable, showing the equivalent 
> > length of the bonded link, which would be calculated as a median of 
> > all the efmCuPmeEquivalentLength in the link.
> > 
> > 2. Add an optional ability to specify Min and Max noise margin 
> > (probably in efmCuPortConfEntry), which would allow one to configure 
> > the working SNR range for the lines in the bonded link, that is:
> > - if the SNR Margin on the copper pair in the bonded link
> > (efmCuPmeSnrMgn) goes below specified Min margin, the pair should 
> > re-train to achieve higher SNR margin than the Min (e.g. 
> > efmCuTargetSnrMgn)
> > - if the SNR Margin on the copper pair goes above specified Max 
> > margin, the pair should/could lower its transmitted power (e.g. using 
> > Power Back-off if efmCuAdaptiveSpectra is true).
> > 
> > 3. Add an ability to specify Min Power Back-off, to allow an operator 
> > to limit the signal transmit power to a lower level than that allowed 
> > by the spectral limitations placed by the efmCuPme2BRegion and 
> > efmCuPme2BsMode.
> > 
> > I would appreciate your comments.
> > 
> > Regards,
> > -E. 

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

---

From: [email-masked]
Date: Mon, 19 Feb 2007 13:33:59 +0100

Edward,

On one hand, the EFM-CU-MUB seems to be a standalone MIB,  including
DSL layer 1 objects and  including bonding objects.

On the other hand, as we discussed in DSL Forum, and as I already
stated on this mailing list, the bonding MIB should not include
duplication of DSL layer 1 objects. We should use separate DSL layer 1
MIB and bonding layer MIB.

It is not clear for me how these two exercises relate. But at least it
seems we should only add to EFM-CU-MIB objects that later on can be
classified as DSL layer 1 specific (regardless of pair being bonded)
xor bonding layer specific (regardless of DSL type used).

As such, I would think that your proposed items:

Item 1: is redundant info in the MIB, calculating median is a job for
application on the MIB, not to be part of the MIB

Item 2:  this is DSL layer 1 specific and to be specified for each line
separately. Applying the same values to each line is about ease of
po[pulation of the MIB object, not to be part of the MIB as separate
object

Item 3:  this is also to be specified for each line. Better work with
absolute PSD limiting objects than with PBO (at least that is how
ADSL&VDSL work in ITU).

Regards,

Frank

Edward Beili wrote:

Regards,
-E.

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Monday, December 11, 2006 16:22
To: Edward Beili; [email-masked]
Cc: Wijnen, Bert (Bert)
Subject: RE: [Hubmib] New things for the EFM-CU-MIB

Dan

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Friday, December 08, 2006 2:53
To: Edward Beili; [email-masked]
Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail)
Subject: RE: [Hubmib] New things for the EFM-CU-MIB

Hi Ed -

My 2 cents.

- Matt

-----Original Message-----
From: Edward Beili [mailto:[email-masked]]
Sent: Friday, December 08, 2006 12:41 AM
To: [email-masked]
Cc: Wijnen, Bert (Bert); Romascanu, Dan (Dan)
Subject: [Hubmib] New things for the EFM-CU-MIB

Hi,

Regards,
-E.

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 20 Feb 2007 17:21:15 +0100

Edward and WG participants.

This question has bee out on the mailing list for quite a while.
Edward already asked for opinions on this back on Dec 7th in a
posting to this mailing list. Since then we've had a couple of
answers that indicate they rather see the current work completed.

So I am inclined to tell the WG that we stick to what we have in
the current draft and do no new additions. I'll give the WG till
the end of this week to speak up more on this topic. If I do not
see more support for Edwards suggested changes, then we'll not
undertake them now.

Bert Wijnen
speaking as HUBMIB WG chair.

> Sent: maandag 19 februari 2007 13:10
> To: [email-masked]
> Cc: Wijnen, Bert (Bert); Romascanu, Dan (Dan); Matt Squire
> I would like to hear your opinion on the proposed additions 
> to the EFM-CU-MIB specified in my original mail below.
> 
> Regards,
> -E.
> 
> 
> > I believe that the WG should focus on completing the 
> current charter 
> > before discussing about any new work 'stemming from ... 
> latest RFPs', 
> > otherwise it risks to run forever trying to catch with the 
> permanently 
> > moving target of the Ethernet technology.
> > 
> > Dan
> > 
> > The second two seem useful.  The first one doesn't seem 
> that useful as 
> > it is easily derived from other entries.  In general, I'm not a big 
> > fan of adding 2nd level data (e.g.
> > > to provide support for some carrier requirements for the Ethernet 
> > > over copper, stemming from some latest RFPs.
> > > 
> > > margin, the pair should/could lower its transmitted power (e.g. 
> > > using Power Back-off if efmCuAdaptiveSpectra is true).
> > > 
> > > 3. Add an ability to specify Min Power Back-off, to allow an 
> > > operator to limit the signal transmit power to a lower level than 
> > > that allowed by the spectral limitations placed by the 
> > > efmCuPme2BRegion and efmCuPme2BsMode.
> > >