Subject: RE: [Hubmib] RE: [EFM] Performance monitoring, installation, trou ble shooting .

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 18 Feb 2002 13:54:14 +0100

> The ifTest table is deprecated in the latest version of the Interfaces
> MIB successor - RFC 2663. The editor of the Ethernet-like MIB should
> correct the text referred by Andy in the new revision of the MIB
> occasioned by the 10GBE support.
> 
> AFAIK, there is no replacement for ifTest. Actually the definition of
> ifTest was generic enough for 'strange un-SNMP-like things'. I do not
> remember all discussions that led to the deprecation of ifTest table,
> but the lack of implementation reports might have been part of this.
> 
> I do think that there is a need for such a function. Still, I prefer it
> to be generic, and not Ethernet-specific. If there is a broader
> interest, ifmib is IMO the place to (re)-do it.
> 
The ifTestTable was already deprecated in RFC2233. So this goes back to
1997. I believe there was some talk (back then) that such a generic
test MIB would be useful, but that it better be defined outside
of the IF-MIB. I have not seen any work on that since then.

Bert
> Regards,
> 
> Dan
>  
> 
> > -----Original Message-----
> > From: Andrew Smith [mailto:[email-masked]]
> > Sent: Sunday, February 17, 2002 9:38 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Hubmib] RE: [EFM] Performance monitoring, 
> > installation, trouble shooting .
> > 
> > 
> > Forgive my ignorance on the history of the following 
> > statement in RFC2665:
> > 
> > "Note that the ifTestTable is now deprecated.  Work is underway to
> >    define a replacement MIB for system and interface testing.  It is
> >    expected that the tests defined in this document will be 
> usable in
> >    this replacement MIB."
> > 
> > The "Ethernet in the First Mile" group in IEEE 802.3 is looking at
> > requirements for management; specific requirements are for 
> > the minimisation
> > of "truck-rolls" (see message thread below - it talks about a 
> > PHY-level
> > loopback requirement). Has there been any further work on 
> > this in any IETF
> > WG? Was the ifTest stuff thrown out because it might do 
> > strange un-SNMP-like
> > things like cut off connectivity for some (arbitrary? 
> > predetermined?) period
> > of time?
> > 
> > Could someone fill me in on the history here?
> > 
> > Thanks,
> > 
> > Andrew Smith
> > 
> > 
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of 
> > Matt Squire
> > Sent: Sunday, February 17, 2002 8:43 AM
> > To: Roy Bynum
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [EFM] Performance monitoring, installation, trouble
> > shooting .
> > 
> > 
> > 
> > 
> > I'll repeat the current status of loopback within OAM.
> > - A ping connectivity test is a requirement.
> > - A loopback mode is a requirement.
> > - Controlling the state of the loopback mode at the other end 
> > of a link
> > is a requirement.
> > 
> > There is also a group of people that believe that the 
> functionality of
> > loopback can be achieved without a loopback mode, but 
> > enhancing the MIBS
> > and the PHY functionality.  They are actively investigating the
> > possibility.  When and if they think they can show equivalent
> > functionality, the results will be presented to the 
> > reflector.  At that
> > point everyone can judge whether the alternate method provides
> > equivalent function.
> > 
> > Loopback itself is a function.  The function is used to 
> > fulfill certain
> > operational requirements.  If those requirements can be met 
> with other
> > methods, and this point can be provent to the group as whole 
> > (including
> > Kent), then the other methods deserve consideration.  I don't 
> > think this
> > is in any way conflicts with Kent's statement (though I'm sure he'll
> > correct me if I'm wrong).
> > 
> > Loopback will remain a requirement until someone can prove 
> to the OAM
> > group that there is a better way.
> > 
> > - Matt
> > 
> > 
> > Roy Bynum wrote:
> > >
> > > Kent,
> > >
> > > I have found that if you do not use strong enough language, 
> > the vendors
> > > that may not have what you require, will attempt to 
> > "interpret" your words
> > > so that they can mean something totally different than what you
> > > intended.  If I am correct, you may want to resend your 
> > comment and use
> > the
> > > words "our operations requires that ability".  If you check 
> > with your
> > > equipment "certification" people for edge access 
> > infrastructure, you may
> > > find that loop back functionality at the physical layer is a hard
> > > requirement, just like it is on T1/T3 infrastructure today. 
> >  I know that
> > it
> > > was a requirement the large service provider that I was 
> > previously with.
> > >
> > > Thank you,
> > > Roy Bynum
> > >
> > > At 04:18 PM 2/15/2002 -0800, [email-masked] wrote:
> > >
> > > >Bob,
> > > >Loopback functionality is important for SBC, our 
> > operations need that
> > > >ability.
> > > >-Kent
> > > >
> > > >Kent G. McCammon
> > > >Broadband Access Group
> > > >SBC Technology Resources, Inc
> > > >4698 Willow Road
> > > >Pleasanton, CA 94588
> > > >925-598-1246
> > > >[email-masked]
> > > >
> > 
> > 
> > _______________________________________________
> > Hubmib mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/hubmib
> > 
> 
> _______________________________________________
> Hubmib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hubmib
> 

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 18 Feb 2002 13:54:14 +0100

Bert

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 19 Feb 2002 09:41:34 -0500

>of the IF-MIB. I have not seen any work on that since then.

there has been work on that; most recent draft was late 1999 with
reasonable consensus level - work was abandoned because of lack of
time by the authors. i have the draft.

kaj

>ifmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ifmib

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 19 Feb 2002 09:41:34 -0500

kaj

Kaj Tesink