Minutes of the Joint Meeting of hubmib and atommib at the 53rd IETF

Minutes of the Joint Meeting of hubmib and atommib at the 53rd IETF

RE: Questions regarding Power Ethernet MIB

Steve,

Thank you for your comments. 

You are correct about issues #1 and #3. We will fix accordingly in the next version of the I-D.

Concerning #2, the SMIv2 recommendation is to make indices non-accessible rather than read-only.

Regards,

Dan

> -----Original Message-----
> From: STEVE.KO <at> DELTA.COM.TW [mailto:STEVE.KO <at> DELTA.COM.TW]
> Sent: Thursday, March 14, 2002 11:51 PM
> To: 'avib <at> PowerDsine.com'; Romascanu, Dan (Dan)
> Subject: Questions regarding Power Ethernet MIB
> 
> 
> Dear Avi and Dan, 
> 
> I'm Steve Ko. I'm working on the Power Ethernet MIB right 
> now. I've got
> three questions regarding Power Ethernet MIB. 
> 
> These questions are: 
> 1) In pethPsePortGroupIndex, the index starts at 1. Why does the index
>    start at 0 in pethMainPseGroupIndex and 
> pethTrapsControlGroupIndex? 
>    Is there any special meaning? Normally, the index starts 
> at 1 in other
>    MIBs.
> 2) Why is pethMainPseGroupIndex not-accessible? Normally, the 
> index is 
>    read-only, isn't it? 
> 3) In pethMainPseBackUpActivatedTrap, pethMainPowerUsageOnTrap, 
>    pethMainPowerUsageOffTrap, shall the pethPsePortGroupIndex 
> be replaced
>    with pethMainPseGroupIndex?
>     
> 
> The MIB file I have is 
> <draft-ietf-hubmib-power-ethernet-mib-01.txt>. You
> reply is highly appreciated. Thanks!
> 
> Regards, 
> 
> Steve Ko 
> Delta Networks, Inc.  
> 
>   
> 
>         
> 

Location Information

I hope this is the correct list to pose my question?  If it isn't could someone please point me right direction
and I apologize!

I would like to keep track of our horizontal cabling on our switches.  Is there a field at the port level of a
switch to do this?  Example:  Port #1 on switch X.X.X.X is connected to location 100-01 out of communication
closet C-1.  I am using the system location field to keep track of the closet information a switch is
installed in.   I am using ANSI/TIA/EIA 568 cabling standard so I know what cable comes out of what closet.  I
would like to be able to query the switch in the C-1 closet and see what locations are cross-connected to it.  

I hope this makes sense and thank you for any information you could provide!

Bill Halpin RCDD/LAN Specialist
Network Engineer 
St. John's Hospital
217-544-64664  ext: 44297
bhalpin <at> st-johns.org

RE: Location Information

There is no current information about location information in the MIBs adopted or in works in this WG.
Actually this does not look like an Ethernet specific issue. Another place to ask would be the Bridge MIB
list - bridge-mib <at> ietf.org.

Regards,

Dan

> -----Original Message-----
> From: Bill Halpin [mailto:BHALPIN <at> st-johns.org]
> Sent: Tuesday, April 09, 2002 5:22 PM
> To: <"Hubmib Mailing List"
> Subject: [Hubmib] Location Information
> 
> 
> I hope this is the correct list to pose my question?  If it 
> isn't could someone please point me right direction and I apologize!
> 
> I would like to keep track of our horizontal cabling on our 
> switches.  Is there a field at the port level of a switch to 
> do this?  Example:  Port #1 on switch X.X.X.X is connected to 
> location 100-01 out of communication closet C-1.  I am using 
> the system location field to keep track of the closet 
> information a switch is installed in.   I am using 
> ANSI/TIA/EIA 568 cabling standard so I know what cable comes 
> out of what closet.  I would like to be able to query the 
> switch in the C-1 closet and see what locations are 
> cross-connected to it.  
> 
> I hope this makes sense and thank you for any information you 
> could provide!
> 
> 
> Bill Halpin RCDD/LAN Specialist
> Network Engineer 
> St. John's Hospital
> 217-544-64664  ext: 44297
> bhalpin <at> st-johns.org
> 
> 
> 
> _______________________________________________
> Hubmib mailing list
> Hubmib <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/hubmib
> 

I-D ACTION:draft-ietf-hubmib-wis-mib-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Ethernet Interfaces and Hub MIB Working Group of the IETF.

	Title		: Definition of Managed Objects for the Ethernet WAN 
                          Interface Sublayer
	Author(s)	: M. Ayers et al.
	Filename	: draft-ietf-hubmib-wis-mib-03.txt
	Pages		: 42
	Date		: 15-Apr-02
	
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets.  In particular, it defines objects for managing the
Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).
The MIB module defined in this memo is an extension of the SONET/SDH
Interface MIB and is implemented in conjunction with it and with the
Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB,
the Interfaces Group MIB, and the Inverted Stack Table MIB.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-hubmib-wis-mib-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-hubmib-wis-mib-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Hubmib WG Last Call

Re: Hubmib WG Last Call

On Sun, 21 Apr 2002, Romascanu, Dan (Dan) wrote:

> This is a Working Group Last Call announcement for the following
> three Internet-Drafts:
> 
> 1) Definitions of Managed Objects for the Ethernet-like Interface Types

Typo corrections for draft-ietf-hubmib-etherif-mib-v3-01.txt:
- Change all occurrences of "ammended" to "amended"
- Change "ifOperStatus" to "ifAdminStatus" in the paragraph of
  Section 3.5 that deals with the mapping of aPhyAdminState

> 2) Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units
>    (MAUs) 

Typo corrections for draft-ietf-hubmib-mau-mib-v3-01.txt:
- Change all occurrences of "ammended" to "amended"
- Change "e.e.," to "i.e.," in Section 2.5.1, 2nd paragraph
- Change "dot2MauType10GigBaseW" to "dot3MauType10GigBaseW"
  in Section 2.5.1, 2nd paragraph
- Change "dot1MauTypeAUI" to "dot3MauTypeAUI" in the DESCRIPTION
  clause of ifMauJabberingStateEnters

> 3) Definitions of Managed Objects for the Ethernet WAN Interface Sublayer

Editorial changes for draft-ietf-hubmib-wis-mib-03.txt:
- Update contact information for Mike Ayers

Regards,

Mike

(Speculative) 10GbE management, UDLR

Ladies & Gents,

Please accept apologies if this posting is too far off topic or is
better raised elsewhere.

The motion picture production industry is in early stages of
defining methods for moving high-resolution uncompressed image
data between equipment (such as film-to-video scanners -- a.k.a.
telecine -- and disk arrays). The desired data rates are
typically in the 3 - 8 Gb/s range. Solutions based on anticipated
availability of merchant-market 10Gb Ethernet may be attractive.

Within today's postproduction facilities, data rates up to
~ 1.5 Gb/s are commonly handled with point-to-point coax links
using SMPTE 292M modulation which is "framed" as a video raster
and operates at 1.485 Gb/s. This is an HDTV standard and is
strictly unidirectional from the source to the receiver.
Unidirectional links can easily be "split" through distribution
amplifiers and can be routed to multiple viewing monitors and
destination equipment bays.

It is common for some types of motion picture postproduction
equipment to have Ethernet interaces for communications and
control functions, separate from the datapath used for bulk
video data. Some users have suggested that the low-cost
10/100/1000 Ethernet connection could be used to manage a
separate unidirectional 10Gb/s transmitter or receiver which
is dedicated to realtime video content.

The attached file shows a highly speculative protocol stack
for real-time operation of a telecine film scanner. The very
bottom of the diagram is of concern here. Note that RFC3077
Unidirectional Link Routing is suggested for dividing traffic
between the 10GbE and 10/100/1000 links. 802.3 bonding or
"trunking" of multiple 10GbE links could be applied if it
is necessary to scale to higher data rates.

A 10GbE transceiver in full compliance with 802.3ae will not
operate as a unidirectional transmitter, as the lack of light
from a receive fiber will create a fault condition which is
reflected out the transmit port. However, an implementation
for this application might intentionally ignore the receive
fault and transmit unidirectionally. I believe that SNMP
management would be pertinent to such unidirectional
ethernet implementations. RFC3077 proponents such as
http://www.udcast.com/udlr/ may suggest other applications
in which these management tools would be useful.

Individuals who are interested in the motion picture
postproduction interconnect problem may wish to contact the
SMPTE N26 or DC28 committees,
http://www.smpte.org/engineering_committees/ .

Thank you for your attention.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  +1 360 863 8340 (voice)  PDT = GMT-0700

RFC 1643 to Historic?

At the IETF52 meeting the possibility of moving RFC 1643 to Historic
status was discussed, as stated in the following item from the minutes:

   o issue on rfc1643 - 2 current versions of the Ethernet mib. - do we
   move it to historic, full standard? Should we put in our current draft
   an explanation of why there are 2 drafts. Some vendors are using
   rfc1643 with private mibs.

To expand on this is more detail, the problem is that RFC 1643 supports
only 10 Mbps Ethernet;  however, because it is a full Standard while the
more up-to-date documents (currently RFCs 2665 and 2668, soon to be
replaced by the two drafts draft-ietf-hubmib-etherif-mib-v3-01.txt and
draft-ietf-hubmib-mau-mib-v3-01.txt, respectively) are only at Proposed
Standard, some vendors reportedly implement RFC 1643 plus private MIB
extensions instead of the up-to-date versions of the EthernetLike-MIB and
MAU-MIB.  It was suggested that the WG should ask that RFC 1643 be moved
to Historic status in order to provide a clear signal to vendors that the
document is out-of-date.

My sense is that this is the right thing to do.  Are there any other
opinions?

Mike