RE: FW: EPON MIB comments (eponDeviceRemoteMACAddressLLIDControl)

[LK] You are right. It seems like the definition of the table mixes 2
things which were not my intention. My intention was not to hold a MAC
address table as in a bridge (which is well covered in the bridge MIB
objects and I had no intention to replica) but to hold a log of ONUs and
their status. The description of the table is indeed confusing and I
will clear it. I think that the MIBs in the table are O.K. I added the
last 3 sentences for clarification in the last draft and they should be
removed as confusing.

Should be:
eponDeviceRemoteMACAddressLLIDTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF EponDeviceRemoteMACAddressLLIDEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION 
            "A table of read-only value that identifies the
             source_address and LLIDs parameter of the remote devices
             in the network. This MacAddress value, as defined in 
             [802.3ah], 30.3.5.1.5, is updated on reception of a
             valid frame with a unicast destination Field or 
             (1) a destination Field equal to the reserved multicast
             address for MAC Control specified in [802.3ah] Annex
             31A, (2) lengthOrType field value equal to the reserved
             Type for MAC Control as specified in [802.3ah] Annex
             31A. (3)an MPCP subtype value equal to the subtype
             reserved for MPCP as specified in [802.3ah] Annex 31A,
             and an LLID as allocated by the OLT. The table is
             defined as Remote MAC address - LLID (RMadL)
             The table is relevant only for an OLT device"
    ::= { eponDeviceControlObjects 2 }




-----Original Message-----
From: Glen Kramer [mailto:[email protected]] 
Sent: Wednesday, January 05, 2005 3:02 AM
To: 'Romascanu, Dan (Dan)'; [email protected]; 'Lior khermosh'
Subject: RE: [Hubmib] FW: EPON MIB comments
(eponDeviceRemoteMACAddressLLIDControl)


[GK] eponDeviceRemoteMACAddressLLIDControl - "Indicates and controls the
resetting of the LLID MAC address log. Setting this object to none(1)
has no action resetLog(2) empties the LLID MAC address log. All data is
deleted. Setting it to useDefaultReporting(3) returns all entries
priorities to their factory-default reporting. Reading this object
always returns useDefaultReporting(3)." The description of this object
seems to match some proprietary EPON device. In the 802.3ah standard,
there is no provision of whether to keep LLID MAC address log. It is not
clear, what does it mean "returns all entries priorities to their
factory-default reporting", since there is no specification for either
"entries" or "factory-default reporting". This object should be removed.

[LK] The OLT and ONUs of an EPON device serves as a distributed virtual
switch where the LLIDs represent bridge ports. This model is behind the
point to point emulation mechanism of clause 65 and of the whole LLID
concept. A bridge have a MAC address to port address table and this
table here serves for exactly the same purpose. It is not a proprietary
implementation. The eponDeviceRemoteMACAddressLLIDControl is a control
attribute for resetting this Table. As a table is a manageable entity I
think such an object is needed. The useDefaultReporting(3) category is a
common option for such attributes as a default setting for tables -
Implementation is according to Vendors preference. I have no special
suggestion for the default value. If people will feel more comfortable I
can remove useDefaultReporting(3) and return in the reading none(1).

[GK] There is no document defining what is "LLID MAC address log". The
phrase "The OLT and ONUs of an EPON device serves as a distributed
virtual switch where the LLIDs represent bridge ports" assumes a
particular implementation. LLIDs do not represent bridge ports. LLID
represent virtual links.  These links may or may not be connected to a
bridge at the OLT. The eponDeviceRemoteMACAddressLLIDControl attribute
refers to an address table in the bridge and has nothing to do with
EPON. Therefore, it should be moved to the bridge MIB.

Regards,
Glen