Subject: Re: [Adslmib] Vector of Profiles MIB

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Nov 2009 2:07:05 +1100

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 <[email-masked]> wrote: 
> Hi Scott,
> 
> How are you?
> See my embedded answers
> 
> Moti M
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, November 09, 2009 10:52 AM
> To: [email-masked]
> Cc: [email-masked]; 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.
> 
> 
> ---- [email-masked] wrote: 
> > on behalf of Deutsche Telekom, I am interested on that item.
> >  
> > Thanks
> > Markus
> >  
> > ________________________________
> > 
> > Von: [email-masked] [mailto:[email-masked]] Im
> > Auftrag von Menachem Dodge
> > Gesendet: Montag, 9. November 2009 09:22
> > An: Menachem Dodge; [email-masked]'
> > 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: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Menachem Dodge
> > Sent: Monday, November 02, 2009 7:07 PM
> > To: [email-masked]'
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/adslmib

---

From: Menachem Dodge <[email-masked]>
Date: Thu, 12 Nov 2009 18:25:00 +0200

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 09, 2009 5:07 PM
To: Moti Morgenstern
Cc: [email-masked]; Menachem Dodge; [email-masked]; [email-masked]
Subject: RE: [Adslmib] Vector of Profiles MIB

Hi Moti,

I am well, thank you.

Regards,

Scott.

---

From: Menachem Dodge <[email-masked]>
Date: Sun, 15 Nov 2009 12:22:53 +0200

Hello Peidaoyu,

Thank you kindly for your comments.

I'd still like to hear from more people on this subject.

Best Regards,
Menachem Dodge

-----Original Message-----
From: peidaoyu [mailto:[email-masked]] 
Sent: Friday, November 13, 2009 4:45 AM
To: Menachem Dodge; [email-masked]
Cc: Moti Morgenstern; [email-masked]
Subject: 答复: [Adslmib] Vector of Profiles MIB

Hi all,
The key difference between the VoP MIB and the RFC5650 is that VoP MIB based
on TR165, and RFC5650 based on TR-129 model. TR-129 model has been used
widely now, and some network operator feedback that the TR129 and
“draft-ietf-adslmib-vdsl2-x” can not meet their requirement. 
Maybe add the VoP MIB to RFC5650 and provide a switch to switch over between
these two models is a good choice.
Best regards
Peidaoyu

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Menachem Dodge
发送时间: 2009年11月13日 0:25
收件人: [email-masked]'
抄送: Moti Morgenstern; [email-masked]
主题: Re: [Adslmib] Vector of Profiles MIB

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.

Thank you kindly,
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 09, 2009 5:07 PM
To: Moti Morgenstern
Cc: [email-masked]; Menachem Dodge; Markus.Freudenberger@t-systems.
com; [email-masked]

Hi Moti,

I am well, thank you.

Regards,

Scott.

---

From: Scott Baillie <[email-masked]>
Date: Sun, 15 Nov 2009 23:00:07 +1100

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.

---

From: <[email-masked]>
Date: Tue, 17 Nov 2009 10:04:52 +0100

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-masked]] 
Gesendet: Sonntag, 15. November 2009 13:00
An: Menachem Dodge; [email-masked]; [email-masked]; Moti Morgenstern; Freudenberger, Markus; [email-masked]; [email-masked]
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.

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.

---

From: Menachem Dodge <[email-masked]>
Date: Mon, 23 Nov 2009 17:21:09 +0200

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-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2009 11:05 AM
To: [email-masked]
Cc: Menachem Dodge; [email-masked]; [email-masked]; Moti Morgenstern; [email-masked]; [email-masked]
Subject: AW: Vector of Profiles MIB

Hello Scott,

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Scott Baillie [mailto:[email-masked]] 
Gesendet: Sonntag, 15. November 2009 13:00
An: Menachem Dodge; [email-masked]; [email-masked]; Moti Morgenstern; Freudenberger, Markus; [email-masked]; [email-masked]
Betreff: Re: Vector of Profiles MIB

Hi all,

Regards,

Scott.

---

From: Scott Baillie <[email-masked]>
Date: Tue, 24 Nov 2009 16:42:36 +1100

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.

---

From: "Umberto Bonollo" <[email-masked]>
Date: Tue, 24 Nov 2009 17:00:59 +1000

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-masked] [mailto:[email-masked]]On
Behalf Of Scott Baillie
Sent: Tuesday, 24 November 2009 3:43 PM
To: Menachem Dodge
Cc: [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hi All,

My position
-----------

Regards,

Scott.

---

From: Menachem Dodge <[email-masked]>
Date: Sun, 29 Nov 2009 17:26:07 +0200

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-masked]] 
Sent: Tuesday, November 24, 2009 3:30 PM
To: [email-masked]; 'Scott Baillie'; Menachem Dodge
Cc: [email-masked]
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-masked] [mailto:[email-masked]] 代表
Umberto Bonollo
发送时间: 2009年11月24日 15:01
收件人: 'Scott Baillie'; Menachem Dodge
抄送: [email-masked]
主题: Re: [Adslmib] Vector of Profiles MIB

Hi Scott,
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-----

Hi All,

My position
-----------

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.
> From: [email-masked]
[mailto:[email-masked]] 
> Cc: Menachem Dodge; [email-masked]; [email-masked]; Moti Morgenstern;
[email-masked]; [email-masked]
> 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.
> An: Menachem Dodge; [email-masked]; [email-masked]; Moti Morgenstern;
Freudenberger, Markus; [email-masked]; [email-masked]
> 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.
> 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.
> 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.

---

From: <[email-masked]>
Date: Mon, 30 Nov 2009 22:42:56 +0100

Hello Menachem,

I agree with your proposal.

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Menachem Dodge [mailto:[email-masked]] 
Gesendet: Sonntag, 29. November 2009 16:26
An: [email-masked]; [email-masked]; 'Scott Baillie'; Moti Morgenstern; Freudenberger, Markus
Cc: [email-masked]
Betreff: RE: [Adslmib] Vector of Profiles MIB

Hello All,

	

Thank you kindly,
Menachem

-----Original Message-----
From: peidaoyu [mailto:[email-masked]]
Sent: Tuesday, November 24, 2009 3:30 PM
To: [email-masked]; 'Scott Baillie'; Menachem Dodge
Cc: [email-masked]
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
-----邮件原件-----

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

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

Regards,

Scott.

> A suggestion has been proposed such that an optional extension to RFC 
be developed that would contain a switch allowing either the current TR-129 model or the TR-165 model to be supported.
> I would appreciate additional members of the WG to come forward and 
> voice
their view.
> Operators need more flexibility of configuring their network. The 
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.
> Be aware that only the profile configurtion of RFC5650 is affected, 
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.
> As you may know from my previous messages on the subject of the Vector 
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 
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 
which should be considered by firmware developers in order to minimise the storage requirements for xDSL configuration in the Access Node.
> A firmware developer can implement the VoP scheme inside the Access 
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.
> Using this approach, the access node gains the advantage of storing 
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 
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 
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.

---

From: <[email-masked]>
Date: Tue, 1 Dec 2009 08:38:00 +0100

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-masked] [mailto:[email-masked]] Im Auftrag von Freudenberger, Markus
Gesendet: Montag, 30. November 2009 22:43
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: [Adslmib] Vector of Profiles MIB

 Hello Menachem,

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Menachem Dodge [mailto:[email-masked]]
Gesendet: Sonntag, 29. November 2009 16:26
An: [email-masked]; [email-masked]; 'Scott Baillie'; Moti Morgenstern; Freudenberger, Markus
Cc: [email-masked]
Betreff: RE: [Adslmib] Vector of Profiles MIB

Hello All,

	

Thank you kindly,
Menachem

-----Original Message-----
From: peidaoyu [mailto:[email-masked]]
Sent: Tuesday, November 24, 2009 3:30 PM
To: [email-masked]; 'Scott Baillie'; Menachem Dodge
Cc: [email-masked]
Subject: 答复: [Adslmib] Vector of Profiles MIB

Hi all,
-----邮件原件-----

Hi Scott,

Regards,
Umberto Bonollo
RFC-5650 co-author

-----Original Message-----

Hi All,

My position
-----------

Regards,

Scott.

their view.
very clear.