On Tue, Dec 03, 2013 at 03:53:27PM -0800, Jarno Rajahalme wrote:
>
> On Dec 3, 2013, at 9:11 AM, Ben Pfaff <b...@nicira.com> wrote:
> > The first precedent is for naming fields by their NXM or OXM names. I
> > seem to recall that I did it that way because those names are already
> > standardized (in the ONF documents, for OXM) or semi-standardized (in
> > nicira-ext.h) and because there was an existing syntax for subfields.
> > However, that may not be a good precedent to follow here, since the
> > short names are more or less carved in stone too due to long use and
> > because we don't care about subfields (yet? If you think subfield
> > prefixes will make sense someday, speak up), so your judgment is
> > important on this.
>
> I do not see a need for prefix tracking for subfields, it really makes sense
> for full addresses only (skipping the beginning of a prefix would make the
> visible address space overlapping, and not using the full address would
> lose the ability to handle host routes). Even for IPv6 you?d NOT need to
> limit the processing to the first 64-bits; if the flow table contains only
> proper prefixes (no host routes) the tree depth will automatically be limited
> to the depth of the longest prefix in the flow table.
OK. That makes sense to me. If we need subfields for some reason
later we can always support both syntaxes.
> > The second precedent is that "groups" is a set of field names rather
> > than a comma-separated list. That is a little cleaner, in my opinion.
> > However, it might not apply here because I think we need an ordered list
> > of prefixes and a set is not ordered.
>
> The ordering is not important, so a set would be fine as well.
OK.
The schema for a set would be like the "groups" field schema, e.g.:
"prefixes": {
"type": {"key": "string", "min": 0, "max": "unlimited"}}
If you think that we should encode the limits in the database schema
(I can see advantages and disadvantages to this) then you could set
the max to 3:
"prefixes": {
"type": {"key": "string", "min": 0, "max": 3"}}
Thanks,
Ben.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
