[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