RE: [EFM] About OAM TLVs
Hi,
I asked for the org-specific information TLV (to be included optionally in
Information OAMPDUs). We already had an org-specific event TLV (for Event
OAMPDUs) and org-specific OAMPDUs in general, and the org-specific info TLV
completes the set. As an example, it can be used during the discovery phase
to negotiate vendor-specific extensions - as no other OAMPDUs can be
exchanged during this phase, this is the only way to achieve such
negotiation.
With regard to its content, the meaning of the OUI in the org-specific TLV
is to define the interpretation of the remaining part of the TLV, and it
says nothing about the organisation making the device which sends or
receives it. So as a vendor, I might define OAM extensions and tell you
what they were so that you could use them too, as a value-add to both our
products, or for industry groups to enhance the protocol and still remain
within the standard.
I hope this satisfactorarily explains the reasoning behind this extension.
Regards,
-- John
--
John Messenger (JMessenger@advaoptical.com)
R&D Software Manager, ADVA Optical Networking Ltd.
Tel: +44-1904 699309 Fax: +44-1904 699378
www.advaoptical.com
"Mind like parachute - only work when open" (Charlie Chan)
-----Original Message-----
From: Yonghong Ren [mailto:ren@appiancom.com]
Sent: 07 August 2003 19:56
To: 'stds-802-3-efm@ieee.org'
Subject: [EFM] About OAM TLVs
1. The most recent draft (2D) defines "Organization Specific Information
TLV". It contains OUI, which is also incuded in the mandatory Local
Information TLV's Vendor Identifier. Why the duplication? Taking up extra 3
bytes is not an issue, but it opens up the question of how to interpret if
it's different from that in Local Information TLV. If they are supposed to
be same, then we have to enforce it.
2. Currently this Organization Specific Information TLV can only be included
in Information PDU, which I think limits its usefulness.
I would propose a generic organization specific TLV that is allowed to be
included in all PDUs except Variable Request and Responsel. Doing so helps
make OAM more useful. For example, when sending dying gasp, an vendor could
include a private TLV that explains what caused the dying gasp.
Appreciate any comments. Thanks.
Yonghong Ren
Appian Communications