Re: [Adslmib] Vector of Profiles MIB

[Menachem Dodge <[e-mail]>]

Hello, 

Is there anyone in the working group who would like to comment on this issue?

At this stage I'm not looking for volunteers, I'm just trying to get a feel of how many of the working group members 
are interested that this Vector Of Profiles MIB be developed.

I would appreciate more people speaking up and sharing their opinions.

Thank you kindly,
Menachem

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, November 09, 2009 5:07 PM
To: Moti Morgenstern
Cc: [e-mail]; Menachem Dodge; [e-mail]; [e-mail]
Subject: RE: [Adslmib] Vector of Profiles MIB

Hi Moti,

I am well, thank you.

If the VoP MIB was to go ahead, do you see it as an extension to
RFC5650 or would it be a completely new MIB with some copy and
paste from RFC5650 to get the new MIB started.

Also, what is your feeling for the demand for such a fine grained
profile model ? In my experience at NEC we are being asked to
provide the opposite approach, ISP's want 4 or 5 service types
( i.e. bronze, silver, gold, platinum ) and most of the configuration
parameters are exactly the same because each DSLAM tends to
service just one type of customer class ( e.g. FTTH or FTTC or FTTB ).

Regards,

Scott.

---- Moti Morgenstern <[e-mail]> wrote: 
> Hi Scott,
> 
> How are you?
> See my embedded answers
> 
> Moti M
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Monday, November 09, 2009 10:52 AM
> To: [e-mail]
> Cc: [e-mail]; Menachem Dodge
> Subject: Re: [Adslmib] Vector of Profiles MIB
> 
> Hi Menachem and Markus,
> 
> I think we should have a discussion first about the
> scope and purpose of the "Vector of Profiles MIB" proposal.
> 
> Can we please address some of the following issues :
> 
> 1. Would the new MIB cover all xDSL technologies like the
>     VDSL2 MIB does ?
> [MM] Yes. It refers to the same TR-129 and G.997.1 documents
> 
> 2. Would the new MIB cover all the parameters defined in G.997.1 ?
> [MM] No. It more-or-less arranges the configuration parameters in a different way.
> However, it does not address the status parameters, the PM parameters, alarm 
> thresholds or notifications.
> 
> 3. Would the only difference between the VDSL2 MIB and the new
>     MIB be the way templates are represented ?
> [MM] In addition to (2) above, the main issue is the way 'templates' are represented. 
> The other issue is that the 'template', which is now called 'VoP', may belong to a 
> single line. If that ('direct') mode is being utilized then the 'template' (VoP) is 
> indexed by the line's ifIndex rather than by an ordered identifier/number.    
> 
> 4. Can you state the things that the new MIB will have that the VDSL2
>     MIB does not have.
> [MM] In principle (ignoring few details) the configuration VoP is the same as what 
> we call 'template'. The differences are: The 'direct' vs. 'indirect' VoP attachment 
> methods, and better (with some compromises) division of the configuration parameters 
> into smaller, focused, profiles. There are also few minor errors (in the vdsl2 MIB) that
> are corrected in the new MIB.
> 
> 5. Can you state the things that the VDSL2 MIB has that the new
>     MIB does not have.
> [MM] First of all, we're talking about the configuration part of the vdsl2 MIB. 
> Other parts remain the same. I think the new MIB preserves the characteristics
> of the vdsl2 MIB, except for the indexing. The VoP and related profiles indices are 
> numeric rather than textual. 
> 
> 6. Is the new MIB intended for embedded use such as in DSLAMs
>     and xDSL line cards ?
> [MM] yes.
> 
> 7. Can you justify having two MIBs that do basically the same thing
>     but do it in a slightly different way ?
> [MM] There is no justification. The reason VoP was invented is because operators felt that
> TR-129 model does not divide the configuration parameters in an optimal way and that may cause
> waste of memory. The issue of 'direct' vs. 'indirect' attachment methods could also be solved 
> with the TR-129 model. Was it pleasant for the BBF to publish two management models within 
> a year or two? Certainly not.
>    
> 8. If you are a developer of xDSL equipment, what criterion would you
>     use to select one MIB or the other ?
> [MM] A very good question. There's no natural mechanism to determine, such as different ifIndex values.
> 
> 
> Regards,
> 
> Scott.
> 
> 
> ---- [e-mail] wrote: 
> > on behalf of Deutsche Telekom, I am interested on that item.
> >  
> > Thanks
> > Markus
> >  
> > ________________________________
> > 
> > Von: [e-mail] [mailto:[e-mail]] Im
> > Auftrag von Menachem Dodge
> > Gesendet: Montag, 9. November 2009 09:22
> > An: Menachem Dodge; '[e-mail]'
> > Betreff: Re: [Adslmib] Vector of Profiles MIB
> > 
> > 
> > 
> > Hello,
> > 
> >  
> > 
> > I haven't received any response to my email of last Monday. 
> > 
> >  
> > 
> > If anyone at all, has an interest in this item of work, please speak up
> > now.
> > 
> >  
> > 
> > Best Regards,
> > 
> > Menachem Dodge
> > 
> >  
> > 
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Menachem Dodge
> > Sent: Monday, November 02, 2009 7:07 PM
> > To: '[e-mail]'
> > Subject: Re: [Adslmib] Vector of Profiles MIB
> > 
> >  
> > 
> > Hello All,
> > 
> >  
> > 
> > In April this year, several emails were exchanged regarding development
> > of a "Vector of Profile" MIB in accordance with the Broadband Forum
> > TR-165 Vector of Profiles document.
> > 
> > See the attached thread.
> > 
> >  
> > 
> > As this issue has been raised again, I would like to see if there is an
> > interest amongst the members of the Working Group in this work.
> > 
> >  
> > 
> > Please share your thoughts on this issue.
> > 
> >  
> > 
> > Best Regards,
> > 
> > Menachem
> > 
> 
> _______________________________________________
> Adslmib mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/adslmib