> 1 and 2 are both in the range [1, 8191], so they would be allowed.
>
> The only disallowed values would be 0 and [8192, UINT16_MAX].
That still feels a bit arbitrary to me. However, I realized that I
should probably restrict "0" as a valid mpid in extended mode. How
about I change cfm_is_valid_mpid to something like this:
static bool
cfm_is_valid_mpid(bool extended, uint64_t mpid)
{
/* 802.1ag specification requires MPIDs to be within the range [1, 8191].
* In extended mode we relax this requirement. */
return mpid >= 1 && (extended || mpid <= 8191);
}
>
>> > When extended mode is enabled, the "normal" mpid is generated with a
>> > hash, but I don't see anything that ensures that the hash value is in
>> > the range [1, 8191].
>>
>> I did this on purpose but perhaps my reasoning was bad. I haven't
>> found a good reason for the restriction to the range 1 to 8191. Since
>> we are running in extended mode I felt at liberty to break the
>> protocol, especially since the hash is only useful for differentiating
>> CCMs in tcpdump. I'm worried about collisions in this field making
>> tcpdump output confusing, so I wanted to use as many bits as possible.
>> That said, one could make an argument for being standards compliant in
>> this field as well. Do you have a strong opinion?
>
> No, I don't. I assumed it was an oversight, but it sounds like you
> thought it through.
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
