On 19/04/18 17:58, Anil Vishnoi wrote: > > ... it is matter of what is the correct model. Given that OpenFlow has > no notion of a zone, I believe ipv4-address-no-zone is the correct type > representing OFPXMT_OFB_IPV4_*. > > Please do not see it from specific project perspective, neither a code > generator should care what is really used and what is not. They go by > what is defined in yang model and generate clean interfaces.
Yes and I am talking very specifically about how OFP models (which *are* openflow-centric) are using ipv4-address, where I believe they should use ipv4-address-no-zone. > To illustrate, can you explain what > happens when a user specifies two matches, which differ only in zone, > for example "1.2.3.4%a" and "1.2.3.4%b"? > > OpenFlow plugin should fail, if it's not supporting zone, but user > can always write an application who uses zone. I think it's none of > mdsal concern on how consumer is using these data type, neither mdsal > should be influence by the context of consumption model when it comes to > implementing defined data types. Except OFP does not fail, it strips the zone and proceeds merrily, for example here: https://github.com/opendaylight/openflowplugin/blob/a862a00411d1eadd7db500711723f9bc273580db/openflowplugin/src/main/java/org/opendaylight/openflowplugin/openflow/md/core/sal/convertor/common/IpConversionUtil.java#L253 . Wouldn't it be better to explicitly express the fact that OpenFlow protocol simply has no notion of a zone? And no, MD-SAL is not taking sides, I am not sure where you inferred that from. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
