Use of binary types where well known yang/ietf types should be used

[kot-begemot-uk]

All models use binary blobs for ip addresses and macs. There is a set of types defined in the ietf-types and ietf-yang-types models imported by OPX which should be used in order to interoperate with any other yang based system.

[rakeshdatta]

I see what you mean.

• ietf-yang-type is defining the mac-address as:
  type string {
  pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
  }

• OPS is defining the mac-address as:
  type binary {
  length "6";
  }

This is an internal data representation.
Can u plz elaborate, with example, what interop issues are you facing due to this?

[kot-begemot-uk]

Any application designed to work with ODL or another yang based system will expect to work with an address as per the IETF model representations. While the internal representation is usually binary the interchange is always the textual one. I have a workaround for it at present - I am presenting "hacked" models to ODL which have all MAC and IP addresses as per IETF notation. At the same time I am loading the ip address parser into CPS as shown in the example on the wiki. As a result I get it to work correctly end-to-end. However, in the long term, I do not think that having two different models - one for presenting and one for internal use is viable. There is a risk that they may get out of sync. A.

…

On 09/03/18 20:18, Rakesh Datta wrote: I see what you mean. * ietf-yang-type is defining it mac-address as: type string { pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; } * OPS is defining it mac-address as: type binary { length "6"; } Can u plz elaborate, with example, what interop issues are you facing? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALkzWOw9KgSSf36yqnBJraf9Ctu6LSO8ks5tcuOdgaJpZM4Sj4lU>.

[rakeshdatta]

Hi Anton,

I did dig deeper into it and I agree with your point. From inter-op perspective, It's always ideal to use the IETF-defined types. However, there are numerous integrations with OPX, that require these types to be customized. That's why we had to define it in the most general and simplest form, i.e. binary. This is a pure design decision.

Modifying these types is not feasible in the next release, because it would need a wide-spread churn.
However, I would do a value assessment of converting these custom types into IETF-types in the subsequent release.If found useful we would incorporate it that time.Will keep you updated in case we decide to do so.

Thanks

[rakeshdatta]

Hi @kot-begemot-uk I am re-evaluating this issue now. To present the case better can you please provide all the information mentioned here: https://github.com/open-switch/opx-docs/wiki/Report-bugs

[kot-begemot-uk]

Present in all versions.

The following elements in dell-base-common.yang are incompatible with all known upstream yang implementations because they are in violation of RFC6021 which clearly determines what their representations should be for interchange purposes.

typedef mac-address {
type binary {
length "6";
}
description
"This type denotes a MAC address as a 6 octet binary number
in network-byte order.";
}
typedef ipv4-address {
type binary {
length "4";
}
description
"This type denotes a IPv4 address as a 4 octet binary number
in network-byte order.";
}

typedef ipv6-address {
type binary {
length "16";
}
description
"This type denotes a IPv6 address as a 16 octet binary number
in network-byte order.";
}

typedef ip-address {
type union {
type base-cmn:ipv4-address;
type base-cmn:ipv6-address;
}

[kot-begemot-uk]

What is the problem you are reporting - Fundamental design fault
Do you have a use case including examples? - yes, stated
Is there a blocker? (Y/N), and include the reasoning if it is a blocker. - it is a blocker for implementing restconf, netconf or any other interop natively without presenting a "hacked" model to the consumer
OPX version that you are using (latest or specific version) - all up to head of tree
Which platform are you using? - Irrelevant as bug is on all platforms
How frequently is the bug reproducible (always, intermittently, and so on)? - Always
Include the steps to reproduce the problem - Just read the rfc please
Include any logs (journalctl -f, opx-show-version, opx-show-system-status, and so on). - not applicable
Have you found a workaround that resolves your problem? - none