Re: [Adslmib] Vector of Profiles MIB

["Romascanu, Dan (Dan)" <[e-mail]>]

Does this mean that you suggest that the extension we are talking about should also cover these? 

Dan
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Tuesday, December 01, 2009 9:38 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Adslmib] Vector of Profiles MIB
> 
> Menachem,
>  
> According point no. 1 in your email I want to add a minor 
> comment: TR-165 deals also with adsl, adsl2 and adsl2plus and 
> not only vdsl2.  
> 
> Markus
> 
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Freudenberger, Markus
> Gesendet: Montag, 30. November 2009 22:43
> An: [e-mail]
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [Adslmib] Vector of Profiles MIB
> 
> 
>  Hello Menachem,
> 
> I agree with your proposal.
> 
> Regards
> Markus
>  
> 
> -----Ursprüngliche Nachricht-----
> Von: Menachem Dodge [mailto:[e-mail]]
> Gesendet: Sonntag, 29. November 2009 16:26
> An: [e-mail]; [e-mail]; 'Scott 
> Baillie'; Moti Morgenstern; Freudenberger, Markus
> Cc: [e-mail]
> Betreff: RE: [Adslmib] Vector of Profiles MIB
> 
> Hello All,
> 
> Although only a small number of WG members have been involved 
> in this discussion, there has nonetheless been strong 
> differences of opinion.
> 
> However, I would like to see if a consensus can be reached 
> based on suggestions already put forward.
> 
> Can we agree on the following:
> 
> 	1. The WG develops an additional optional Vdsl2 
> configuration extension MIB based on TR-165. 
> 	   	a. This extension contains a "scalar variable" 
> or "switch" used by the manager and the SNMP agent to negotiate 
>                whether VDSL2 configuration will be done by 
> the TR-165 VoP Method or the TR-129 RFC 5650 Method. 
> 	      b. The default of the "scalar variable" is TR-129 
> RFC 5650 Method. 
> 	      c. If either the SNMP manager or the SNMP Agent 
> do not support the extension MIB and hence the "switch", 
>                configuration will be done by TR-129 RFC 5650.
> 	2. RFC 5650 remains unchanged. 
> 	3. Support of RFC 5650 is mandatory.
> 	
> Please indicate agreement or disagreement to the above.
> 
> Thank you kindly,
> Menachem
> 	
> 
> 
> -----Original Message-----
> From: peidaoyu [mailto:[e-mail]]
> Sent: Tuesday, November 24, 2009 3:30 PM
> To: [e-mail]; 'Scott Baillie'; Menachem Dodge
> Cc: [e-mail]
> Subject: 答复: [Adslmib] Vector of Profiles MIB
> 
> Hi all,
> I don't think that 10-100 profiles are enough for used to 
> manage order of
> 10^5 to 10^6 xDSL lines, maybe it's enough for adsl, but it’s 
> not enough for vdsl2. Furthermore, the memory is not the only 
> reason to define TR165.
> In FTTx or DLM or DSM cases the TR165 model is more suitable, 
> it makes configuration simpler. 
> As there are two many differences between these two models, 
> the translation between TR-129 model and TR-165 model is 
> almost impossible, and makes no sense. Maybe a switch is 
> suitable, then it up to the operator to choose a management 
> model it prefers to.
> Regards,
> PeiDaoyu
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
> Umberto Bonollo
> 发送时间: 2009年11月24日 15:01
> 收件人: 'Scott Baillie'; Menachem Dodge
> 抄送: [e-mail]
> 主题: Re: [Adslmib] Vector of Profiles MIB
> 
> Hi Scott,
> I am in agreement with your position in 1. and 2. below.
> It must be possible for RFC-5650 to work independently of 
> possible optional VOP add-on.
> From very large projects in the field I'm aware of, 
> typically,  10-100 profiles are used to manage order of 10^5 
> to 10^6 xDSL lines.
> 
> Regards,
> Umberto Bonollo
> RFC-5650 co-author
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Scott Baillie
> Sent: Tuesday, 24 November 2009 3:43 PM
> To: Menachem Dodge
> Cc: [e-mail]
> Subject: Re: [Adslmib] Vector of Profiles MIB
> 
> 
> Hi All,
> 
> I would like to summarise my position on the Vector of 
> Profiles MIB proposal so that it is clearer what my position 
> is, but I would like to hear the views of the group on these issues.
> 
> My position
> -----------
> 1. I would prefer that the TR-165 enhancements be implemented
>    at a lower layer and hence no need to change the RFC-5650
>    management interface. The reasons for this are covered
>    in my previous post.
> 2. If the RFC-5650 extension MIB was to go ahead anyway,
>    I would be very much opposed to the effort unless :
>    a) The TR-129 model is mandatory and the TR-165 model is
>       optional. Hence, a SNMP agent MUST implement the template
>       model but MAY implement the VoP model.
>    b) The tables in RFC-5650 are not altered in any way, only
>       one scalar variable is added to RFC-5650. The scalar
>       variable would be writeable and have 2 values.
>    c) When a SNMP agent is configured to operate in TR-165
>       mode, it must also be fully manageable by a SNMP
>       manager that only understands the TR-129 model.
> 
> Regards,
> 
> Scott.
> 
> On Mon, 2009-11-23 at 17:21 +0200, Menachem Dodge wrote:
> > Hello,
> > 
> > So far only a small number of WG members have offered their 
> opinion as 
> > to
> whether or not the TR-165 management model should be developed.
> > 
> > A suggestion has been proposed such that an optional 
> extension to RFC 
> > 5650
> be developed that would contain a switch allowing either the 
> current TR-129 model or the TR-165 model to be supported.
> > 
> > The opinions thus far have been divided, even regarding 
> this optional
> extension.
> > 
> > I would appreciate additional members of the WG to come forward and 
> > voice
> their view.
> > 
> > Thank you kindly,
> > Menachem Dodge
> > 
> > 
> > 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]] 
> > Sent: Tuesday, November 17, 2009 11:05 AM
> > To: [e-mail]
> > Cc: Menachem Dodge; [e-mail]; [e-mail]; Moti 
> > Morgenstern;
> [e-mail]; [e-mail]
> > Subject: AW: Vector of Profiles MIB
> > 
> > Hello Scott,
> > 
> > I understand your proposal but it does not address the 
> complete issue. 
> > Operators need more flexibility of configuring their network. The 
> > approach
> of TR-129 does not scale from the OSS point view as it 
> multiplies the amount of different xDSL profiles/templates. 
> In practice, the MIB from the DSLAM (In this case represeting 
> the TR-129 object model) is usually mapped 1:1 into the EMS 
> and its data model. In FTTx deployment scenarios with 
> specific requirements depending on the PSD shaping on the 
> remote DSLAM, noise margins, specific OLR features and INP 
> configurations, TR-129 causes a multiplication of templates 
> as every single parameter variation ends up in a new template 
> and/or channel or line profile.
> > 
> > Therefore TR-165 needs to be implemented at the SNMP management 
> > interface
> and in the associated EMS to take full effect.
> > 
> > Be aware that only the profile configurtion of RFC5650 is affected, 
> > all
> other parts are untouched and can stay as they are today. In 
> order to not skip the template approach from TR-129 
> completely, a switch, as proposed by Peidaoyu from Huawei, 
> might be a good solution.
> > 
> > Regards
> > Markus
> > 
> >     
> > -----Ursprüngliche Nachricht-----
> > Von: Scott Baillie [mailto:[e-mail]]
> > Gesendet: Sonntag, 15. November 2009 13:00
> > An: Menachem Dodge; [e-mail]; [e-mail]; Moti 
> > Morgenstern;
> Freudenberger, Markus; [e-mail]; [e-mail]
> > Betreff: Re: Vector of Profiles MIB
> > 
> > Hi all,
> > 
> > As you may know from my previous messages on the subject of 
> the Vector 
> > of
> Profiles MIB proposal, I do not believe that it is a good 
> idea to introduce another VDSL2 management interface which is 
> not compatible with the existing management interface ( 
> RFC5650 ) unless there are compelling and significant reasons 
> to do so.
> > 
> > Introducing an incompatible VDSL2 management interface does not 
> > benefit
> the xDSL industry, it causes harm because NMS/EMS 
> applications will now have to support two interfaces instead of one.
> > 
> > I consider the Vector of Profiles scheme to be an implementation 
> > decision
> which should be considered by firmware developers in order to 
> minimise the storage requirements for xDSL configuration in 
> the Access Node.
> > But this implementation decision is a low level detail and 
> should not
> affect the VDSL2 management interface.
> > 
> > A firmware developer can implement the VoP scheme inside the Access 
> > Node
> while remaining 100% compatible with the RFC5650 management 
> interface. What is required is to provide a mapping between 
> the template name and the vector, and this mapping can be 
> kept hidden so that the operator has no knowledge of the 
> internal implementation details.
> > 
> > Let me state my proposal in a different way in case what I said was 
> > not
> very clear.
> > 
> > 1. Internally, the xDSL configuration is stored using
> >    the efficient VoP scheme.
> > 2. In the firmware, a mapping exists between the RFC5650
> >    template name and the internal vector that stores the
> >    configuration for that template. This mapping may take
> >    the form of a hash map for example.
> > 3. When a SNMP request arrives to read a row from the
> >    line profile or channel profile tables
> >    ( xdsl2LineConfProfTable,
> >      xdsl2LineConfProfModeSpecTable
> >      xdsl2LineConfProfModeSpecBandUsTable,
> >      xdsl2ChConfProfileTable )
> >    the access node will consult its hash map and find
> >    the corresponding vector. The access node will then
> >    retrieve the data from the vector and return it in
> >    the form of a SNMP row.
> >    What this means is that storage of the xDSL
> >    configuration data is decoupled from the MIB
> >    representation of the data. Most modern SNMP agent's
> >    ( such as the Net SNMP agent ) supports decoupling
> >    of the underlying storage as I have described.
> > 4. When a SNMP request arrives to write a row into
> >    the line profile or channel profile tables, the
> >    access node must either create a new vector to
> >    store the data of reference an existing vector
> >    which already contains that data.
> > 
> > Using this approach, the access node gains the advantage of storing 
> > the
> xDSL configuration data efficiently while remaining 
> compatible with the existing SNMP management interface.
> > 
> > The algorithm that I have described above would need to be 
> specified 
> > in
> more detail, but I am sure that every one here is an engineer 
> and at least understands the concept that I am proposing.
> > 
> > In conclusion, I think that the broad band forum should create a 
> > companion
> document that goes together with TR165 which specifies an 
> algorithm ( similar to what I have proposed above ) that 
> firmware developers can use to map between 5650 templates and 
> VoP vectors instead of specifying a new VDSL2 management 
> interface at the IETF.
> > 
> > Regards,
> > 
> > Scott.
> > 
> > 
> > _______________________________________________
> > Adslmib mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/adslmib
> _______________________________________________
> Adslmib mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/adslmib
>