This is an "umbrella bug", additional bugs for specific deficiencies will be filed separately.

Symptoms:

Current yangtool generate code for MacAddress, IPv4Address, IPv6Address etc based on what is a "human" description of the object as a String, not its network or in-packet binary representation.

This results in the following deficiencies:

1. Object data is not the normalized form.

Ietf yang type interpretation does not yield normalized form of the data, because yang does not and will not in the immediate future describe normalized data forms.

While this is not critical for v4 and Macs, it is a critical v6 issue as v6 addresses can have multiple identical representations and should be normalized prior to comparison.

Example: http://docs.oracle.com/javase/7/docs/api/java/net/Inet6Address.html

Due to the fact that the fundamental v6 types in ODL are yang derived and not normalized identical v6 addresses will not be matched correctly by ODL.

Several projects (bgpcep, openflowjava, etc) have different implementations of v6 normalization per project which are not guaranteed to be compatible between themselves. This makes most ODL configurations with more than one project artifact loaded v6-buggy. It also leads to proliferation of bug-prone conversion code for ip addresses, macs and other fundamental network objects (each project has its own). This defeats most of the benefits of centralized model driven generation.

2. Application of unnecessary conversions and checks for data incoming from the southbound (network).

Data coming from the network is already in binary form. It is converted to a string form at least once for each data item in each packet and checks are applied as if it was entered by human. This is unnecessary for most use cases and leads to a penalty in the range of thousands (or more) of instructions for each transaction.

3. All routing and prefix match algorithms are designed to operate on the binary form of Macs, Addresses and Prefixes. As a result no off-the-shelf routing algorithm can be applied directly to the resulting yang generated types without incurring major conversion penalties. This in turn, imposes major limitations on all upstream development in ODL.