[ovs-dev] [cfm_v2 8/9] cfm: Eight byte MPIDs in extended mode.
Ben Pfaff
blp at nicira.com
Fri Sep 9 20:24:42 UTC 2011
[adding ovs-dev back]
On Fri, Sep 09, 2011 at 01:23:58PM -0700, Ben Pfaff wrote:
> On Fri, Sep 09, 2011 at 01:14:44PM -0700, Ethan Jackson wrote:
> > > I'd be tempted to say that mpids must be in either range [1, 8191] or
> > > [UINT16_MAX + 1, UINT64_MAX], which would allow cfm_is_valid_mpid() to
> > > be valid even for extended mpids, but I'll leave that up to you.
> >
> > When configuring this by hand it's fairly convenient to be able to set
> > the mpid to low values like 1 or 2. I regularly assign 1 to eth1 2 to
> > eth2 etc. I don't really see a good reason to restrict that in
> > extended mode.
>
> 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].
>
> > > 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.
More information about the dev
mailing list