Re: Vector of Profiles MIB

Yes, it has to. BTW RFC 5650 does this already if you look into the abstract section. 

-----Ursprüngliche Nachricht-----
Von: Romascanu, Dan (Dan) [mailto:[email protected]] 
Gesendet: Dienstag, 1. Dezember 2009 11:04
An: Freudenberger, Markus; [email protected]
Cc: [email protected]
Betreff: RE: [Adslmib] Vector of Profiles MIB

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

Dan
 

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Tuesday, December 01, 2009 9:38 AM
> To: [email protected]
> Cc: [email protected]
> 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: [email protected]
> [mailto:[email protected]] Im Auftrag von Freudenberger, Markus
> Gesendet: Montag, 30. November 2009 22:43
> An: [email protected]
> Cc: [email protected]; [email protected]
> Betreff: Re: [Adslmib] Vector of Profiles MIB
> 
> 
>  Hello Menachem,
> 
> I agree with your proposal.
> 
> Regards
> Markus
>  
> 
> -----Ursprüngliche Nachricht-----
> Von: Menachem Dodge [mailto:[email protected]]
> Gesendet: Sonntag, 29. November 2009 16:26
> An: [email protected]; [email protected]; 'Scott Baillie'; Moti 
> Morgenstern; Freudenberger, Markus
> Cc: [email protected]
> 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:[email protected]]
> Sent: Tuesday, November 24, 2009 3:30 PM
> To: [email protected]; 'Scott Baillie'; Menachem Dodge
> Cc: [email protected]
> 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
> -----邮件原件-----
> 发件人: [email protected] [mailto:[email protected]] 代表
> Umberto Bonollo
> 发送时间: 2009年11月24日 15:01
> 收件人: 'Scott Baillie'; Menachem Dodge
> 抄送: [email protected]
> 主题: 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: [email protected] [mailto:[email protected]]On
> Behalf Of Scott Baillie
> Sent: Tuesday, 24 November 2009 3:43 PM
> To: Menachem Dodge
> Cc: [email protected]
> 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: [email protected]
> [mailto:[email protected]]
> > Sent: Tuesday, November 17, 2009 11:05 AM
> > To: [email protected]
> > Cc: Menachem Dodge; [email protected]; [email protected]; Moti 
> > Morgenstern;
> [email protected]; [email protected]
> > 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:[email protected]]
> > Gesendet: Sonntag, 15. November 2009 13:00
> > An: Menachem Dodge; [email protected]; [email protected]; Moti 
> > Morgenstern;
> Freudenberger, Markus; [email protected]; [email protected]
> > 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
_______________________________________________
Adslmib mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/adslmib