Re: [EFM] Question about revision field in local information TLV
Don't you think that the passage in the draft should mention the effect of wrapping. From the sender point of view, it is clear that incrementing the revision when the value is 255 causes 0 > 255. But, the receiver may have a problem with the comparison.
From: Kevin Daines [mailto:Kevin.Daines@WORLDWIDEPACKETS.COM]
Sent: Tue 4/13/2004 7:59 PM
Subject: Re: [EFM] Question about revision field in local information TLV
The revision field was added as a mechanism to reduce unnecessary processing of duplicate Information OAMPDUs. The revision field starts at 0 and is "incremented each time something in the Information TLV changes." Using this definition, a value of 1 is newer than 0, 2 is newer than 1 ... 255 is newer than 254 and 0 is newer than 255. The 8-bit field wraps at 255.
The behavior of the revision field is comparable to the 16-bit sequence number found in Event Notification OAMPDUs (see 184.108.40.206).
Hope this helps.
Editor, EFM OAM
From: owner-stds-802-3-efm@LISTSERV.IEEE.ORG on behalf of Stephen Suryaputra
Sent: Tue 4/13/2004 12:05 PM
Subject: [EFM] Question about revision field in local information TLV
I have a question on the revision field in local information TLV. The clause 220.127.116.11 mentions that
the revision field must start at 0 and gets incremented whenever the content of the local info TLV changes. The receiver may check for the revision field to figure out if the current local info TLV changes. Have anybody thought of the possibility of that field wrap up and how do OAM client handle that?
This probably need to be clarified and worked on for the next draft.
Appreciate any feedback.