Re: [Adslmib] Vector of Profiles MIB

"sbaillie@bigpond.net.au" <sbaillie@bigpond.net.au> Mon, 09 November 2009 15:06 UTC

Return-Path: <sbaillie@bigpond.net.au>
X-Original-To: adslmib@core3.amsl.com
Delivered-To: adslmib@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE623A68A6 for <adslmib@core3.amsl.com>; Mon, 9 Nov 2009 07:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.734
X-Spam-Level: *
X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, FH_FAKE_RCVD_LINE_B=5.777]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhkELpNEjJWg for <adslmib@core3.amsl.com>; Mon, 9 Nov 2009 07:06:41 -0800 (PST)
Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by core3.amsl.com (Postfix) with ESMTP id 941D93A687D for <adslmib@ietf.org>; Mon, 9 Nov 2009 07:06:40 -0800 (PST)
Received: from nschwotgx02p.mx.bigpond.com ([61.9.190.9]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20091109150705.ICEA28093.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Mon, 9 Nov 2009 15:07:05 +0000
Received: from nschwwebs01p ([61.9.190.9]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20091109150705.TYID19767.nschwotgx02p.mx.bigpond.com@nschwwebs01p>; Mon, 9 Nov 2009 15:07:05 +0000
Received: from 124.190.58.101 by webmail.bigpond.com; Mon, 9 Nov 2009 15:07:03 +0000
Message-ID: <17964993.1257779225157.JavaMail.root@nschwwebs01p>
Date: Tue, 10 Nov 2009 2:07:05 +1100
From: "sbaillie@bigpond.net.au" <sbaillie@bigpond.net.au>
To: Moti Morgenstern <Moti.Morgenstern@ecitele.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
Sensitivity: Normal
X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4AF83019.0085,ss=1,fgs=0
Cc: Menachem Dodge <Menachem.Dodge@ecitele.com>, "adslmib@ietf.org" <adslmib@ietf.org>, "Markus.Freudenberger@t-systems.com" <Markus.Freudenberger@t-systems.com>
Subject: Re: [Adslmib] Vector of Profiles MIB
X-BeenThere: adslmib@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: ADSLMIB <adslmib.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/adslmib>
List-Post: <mailto:adslmib@ietf.org>
List-Help: <mailto:adslmib-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 15:06:42 -0000

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