[ovs-dev] [cfm_v2 8/9] cfm: Eight byte MPIDs in extended mode.

[Ethan Jackson]

> 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.
>