Does forwarding action have to be mandatory? In some vendor implementations, remarks/comments are their own sequence id entry, and do not have a forward or logging action. Another way to accommodate this might be a NOOP forwarding action.

Can anyone give more details for me to understand the functionality of "install-protocol-eq" which comes in openconfig-routing-policy model?
What if there are multiple instances of same protocol: like ospf-100 and ospf-200?

If possible can you give an example with equivalent CLI commands?

leaf install-protocol-eq {
type identityref {
base oc-pol-types:INSTALL_PROTOCOL_TYPE;
}
description
"Condition to check the protocol / method used to install
the route into the local routing table";
}

Hi,

All the other yang modules defines a top level grouping.
Please add a top level grouping for Telemetry module as well, which can help in making it consistent with the other yang models.
Also this helps in adding features on top of this model.

Looking at something like,
@@ -29,6 +29,12 @@
reference "0.2.0";
}

• grouping telemetry-system-top {

• description
  

•  "Top-level grouping for interface configuration and
  

•  operational state data";
  

  container telemetry-system {
  description
  "Top level configuration and state for the
  @@ -438,6 +444,7 @@
  }
  }
  }
• }

// extension statements

@@ -722,6 +729,8 @@
}
}

• uses telemetry-system-top ;

// data definition statements

// augment statements

Thanks!
Bijoy.

Looking at:

https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang#L161-L170

It came from RFC 7277, which has:

        list address {
          key "ip";
          description
            "The list of configured IPv4 addresses on the interface.";

          leaf ip {
            type inet:ipv4-address-no-zone;
            description
              "The IPv4 address on the interface.";
          }
          choice subnet {
            mandatory true;
            description
              "The subnet can be specified as a prefix-length, or,
               if the server supports non-contiguous netmasks, as
               a netmask.";
            leaf prefix-length {
              type uint8 {
                range "0..32";
              }
              description
                "The length of the subnet prefix.";
            }
            leaf netmask {
              if-feature ipv4-non-contiguous-netmasks;
              type yang:dotted-quad;
              description
                "The subnet specified as a netmask.";
            }
          }
        }

IOW, the choice subnet is mandatory. The openconfig-if-ip model only has prefix-length, which is mandatory in the equivalent IPv6 definition, so should the IPv4 prefix-length be mandatory also?

Cheers,

Einar

While it is probably ok to use require-instance on a leafref in YANG 1.1, where the restriction has been relaxed, YANG 1.0 does not support it. If anything it complains about it. Is there a plan to have a YANG 1.0 model for bgp-policy that does not use require-instance?

(1) In the last update of this module, the notion of indexing next-hops for a given static-route got introduced. This change now makes it possible for multiple entries in the “next-hops” list to have the same “next-hop IP address”. Are there any valid use-cases where the combination of “config/next-hop and interface-ref/config/*” under /local-routes/static-routes/static/next-hops wouldn’t be unique?
If there are no such use-cases, then please consider adding an appropriate “unique” statement to the next-hops list.

(2) “metric” and “recurse” are currently specified under /local-routes/static-routes/static/next-hops/next-hop/config (specified per-next-hop for a given static-route). Can these knobs be also made available under /local-routes/static-routes/static/config (allow specification per static-route)?

Issue 1 :-for openconfig-if-ethernet.yang ,there is augment statement like :-
augment "/oc-if:interfaces/oc-if:interface" {
when "oc-if:type = 'ift:ethernetCsmacd'" {

But when we compile using confdc compiler it throws error saying type is not found in openconfig-interfaces.yang.
However when i change it to :-
augment "/oc-if:interfaces/oc-if:interface" {
when "oc-if:config/oc-if:type = 'ift:ethernetCsmacd'" {

Now it compiles fine i.e., when i specify the container in which type is present.

Issue 2 :-all the must expression present in openconfig-terminal-device.ynag are failing.Below is the error:-
g: The 'must' expression will fail: the node 'LOGICAL_CHANNEL' from module 'openconfig-terminal-device' (in node 'logical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:453: warning: The 'must' expression will fail: the node 'assignment-type' from module 'openconfig-terminal-device' (in node 'logical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:453: warning: The 'must' expression will fail: the node 'LOGICAL_CHANNEL' from module 'openconfig-terminal-device' (in node 'logical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:467: warning: The 'must' expression will fail: the node 'assignment-type' from module 'openconfig-terminal-device' (in node 'optical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:467: warning: The 'must' expression will fail: the node 'OPTICAL_CHANNEL' from module 'openconfig-terminal-device' (in node 'optical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:467: warning: The 'must' expression will fail: the node 'assignment-type' from module 'openconfig-terminal-device' (in node 'optical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:467: warning: The 'must' expression will fail: the node 'OPTICAL_CHANNEL' from module 'openconfig-terminal-device' (in node 'optical-channel' from 'openconfig-terminal-device') is not found
openconfig-terminal-device.yang:820: warning: The 'must' expression will fail: the node 'operational-modes' from module 'openconfig-terminal-device' (in node 'components' from 'openconfig-platform') is not found
openconfig-terminal-device.yang:820: warning: The 'must' expression will fail: the node 'operational-modes' from module 'openconfig-terminal-device' (in node 'components' from 'openconfig-platform') is not found
openconfig-terminal-device.yang:820: warning: The 'must' expression will fail: the node 'operational-modes' from module 'openconfig-terminal-device' (in node 'components' from 'openconfig-platform') is not found
openconfig-terminal-device.yang:820: warning: The 'must' expression will fail: the node 'operational-modes' from module 'openconfig-terminal-device' (in node 'components' from 'openconfig-platform') is not found

Thanks,
Vivek Prasad

destination-group/state below subscription need to have "config false" specified.

  list subscription {        
      ....
      container destination-groups {
       ...
         list destination-group {

         container state {

•          config false;
          description
          "State information related to telemetry
           destinations";
  

Not sure if it's been noticed before, but:

    leaf identifier {
      type identityref {
        base "pt:install-protocol-type";
      }
      description
        "The protocol identifier for the instance";
    }

...should be:

    leaf identifier {
      type identityref {
        base "pt:INSTALL_PROTOCOL_TYPE";
      }
      description
        "The protocol identifier for the instance";
    }

Hi,
Looking at the ETHERNET_PMD_TYPE in openconfig-transport-types we are missing few of the ethernet compliance codes:

• ETH_40GBASE_CSR4
• ETH_40GBASE_SR_BD
• ETH_40G_AOC

Any reason for not having these codes and what should be the expected output of the field oc-transceiver:ethernet-compliance-code for such transceivers.

In peer-group/afi-sfis each afi-safi list item pulls in the route-selection-options container (grouping bgp-common-route-selection-options). This is probably incorrect. I don't think any implementation would allow route-selection options to vary based on peer group since that would introduce inconsistent best path selection and the possibility of routing loops, route oscillation, etc.

(1) /routing-policy/policy-definitions/policy-definition/statements/statement/conditions/match-interface/config/:
As per the current schema, only one match-interface can be specified for a given statement. Should there be a provision to add a list of interfaces?

2. /routing-policy/policy-definitions/policy-definition/statements/statement/actions/bgp-actions/set-community/reference/config/community-set-ref:
   As per the current schema, only one community-set can be referenced in a given action. Should this be made a leaf-list?

(3) /routing-policy/policy-definitions/policy-definition/statements/statement/actions/bgp-actions/set-ext-community/reference/config/ext-community-set-ref:
As per the current schema, only one ext-community-set can be referenced in a given action. Should this be made a leaf-list?

Description*
In the oc schema under the hellos we have hello-interval and refresh reduction. This needs to be changed.
Hence i request this modification has to be happened in the OC schema. I have filed this PR as Modification

edit]
[email protected]# set openconfig-mpls:mpls signaling-protocols rsvp-te interface-attributes interface all hellos ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> config               Configuration parameters relating to RSVP
                       hellos
[edit]
[email protected]# set openconfig-mpls:mpls signaling-protocols rsvp-te interface-attributes interface all hellos config ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  hello-interval       set the interval in ms between RSVP hello
                       messages (1..60 seconds)
  refresh-reduction    enables all RSVP refresh reduction message
                       bundling, RSVP message ID, reliable message delivery
                       and summary refresh
[edit]
[email protected]# set openconfig-mpls:mpls signaling-protocols rsvp-te interface-attributes interface all hellos config    

Hello,
I see that there is a model for l2 network instances but I can't find information related to bridging domains (IRB, vlans, mac address table, etc.). Is that missing or did I overlooked something?

Thanks!
David

Hello,

'PROT_OTN' and 'PROT_ETHERNET' should be prefixed by the external namespace oc-opt-types in their definition :

   uses terminal-otn-protocol-top {
      when "config/logical-channel-type = **'PROT_OTN'**" {
        description
          "Include the OTN protocol data only when the
          channel is using OTN framing.";
      }
    }
    uses terminal-ethernet-protocol-top {
      when "config/logical-channel-type = **'PROT_ETHERNET'**" {
        description
          "Include the Ethernet protocol statistics only when the
          protocol used by the link is Ethernet.";
      }
    }

Hi OpenConfig team,

This is an enhancement request.

In this model https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform.yang is it possible to add platform-component-properties-top under platform-subcomponent-ref-top.

Basically, allow subcomponents to have properties too.

Thanks,
Dmitry.

In line 596 of release/models/network-instance/openconfig-network-instance.yang

base "pt:install-protocol-type";
needs to be

•   base "pt:INSTALL_PROTCOL_TYPE";
  

Hello,

I'm implementing prefix-limit feature for GoBGP using OpenConfig yang model and have a proposal for the model.

Now prefix-limit configuration knob is under each address family specific item.
(ipv4-unicast-group, ipv6-unicast-group etc...)

https://github.com/openconfig/public/blob/master/release/models/bgp/openconfig-bgp-multiprotocol.yang#L718-L727

When we auto-generate a configuration header file for some specific language
(for my case, golang),
current model leads to generate redundant items.

For example, when afi-safi-name is ipv4-unicast, we don't need these lines

Since prefix limit configuration is general among address families (like graceful restart), how about making it the same way as graceful restart?

I think this makes the model more simple and clean.

Hello,

I can't validate data with this defintion:

augment "/oc-platform:components/oc-platform:component" {
when "/oc-platform:components/oc-platform:component/" +
"oc-platform:state/oc-platform:type = 'OPTICAL_CHANNEL'" {
description
"Augment is active when component is of type
OPTICAL_CHANNEL";
}
description
"Adding optical channel data to physical inventory";

uses terminal-optical-channel-top {
}

}
In fact 'OPTICAL_CHANNEL' is not typed oc-platform-types:OPENCONFIG_HARDWARE_COMPONENT or oc-platform-types:OPENCONFIG_SOFTWARE_COMPONENT

type in openconfig-platorm.yang module is defined like
leaf type {
type union {
type identityref {
base oc-platform-types:OPENCONFIG_HARDWARE_COMPONENT;
}
type identityref {
base oc-platform-types:OPENCONFIG_SOFTWARE_COMPONENT;
}
}

I am not sure how the first 3 string patterns are usable in this typedef because the sub-type is unspecified.

Hi,

Similar to reported issues in other models I've encountered both compile errors and data validation errors with openconfig-network-instance.

1. While compiling with confdc I hit several errors related to paths in when statements. Below is one example, there were at least 10 others that need to be addressed that I have not included to keep this note brief.

openconfig-network-instance.yang:100: error: the node 'type' from module 'openconfig-network-instance' (in node 'network-instances' from 'openconfig-network-instance') is not found

In this case I modified this line:
when "../type = 'L2VSI' or ../type = 'L2P2P'" +
" or ../type = 'L2L3'" {

to this and the compilation succeeded:
when "config/type = 'L2VSI' or config/type = 'L2P2P'" +
" or config/type = 'L2L3'" {

2. After fixing the compile issues I've run into problems where the when statements did not validate data properly. One failing example from the protocols container is below.

        uses oc-loc-rt:local-static-top {
          when "../config/identifier = 'STATIC'" {
            description
              "Include static route parameters only when the
              protocol is set to static";
          }
          description
            "Configuration and state parameters relating to
            static routes";
        }
   

I added the prefix 'oc-pol-types' to the STATIC value to address this. I suspect other when statements in this model have the same issue but did not specifically check them all.

Thanks,
Paul

There is some ambiguity about what peer-group configuration should be inherited by a neighbor that is referenced to use that peer-group. The same for global BGP configuration inherited by a peer-group. For example, if afi-safi-X is enabled and afi-safi-Y is disabled in the peer-group configuration and only afi-safi-Y is enabled in the neighbor configuration, which of the following is expected:

(a) the neighbor has only afi-safi Y enabled, because the neighbor configuration of afi-safi list is authoritative
(b) the neighbor has afi-safi X and Y enabled, because each afi-safi element in the list is individually inherited

There are many other examples of this.

Somehow this needs to be specified in the model or else in a companion document.

Hi,

Checked in openconfig-transport-types.yang. QSFP_PLUS is missing.
Any reason for this ?

Thanks,
Prasenjit

The match-as-path-set container has a match-set-options leaf that uses the typedef providing ANY, ALL and INVERT options. If we assume, as implied by the model, that an as-path-set is a concatenated set of strings, each of which is a regular expression used for AS path matching, then it's hard to understand how ANY, ALL or INVERT logic would be applied, since the regular expression already encodes these notions. I think it can be argued that the common match-set-options should not be applied to as-path-sets.

The inclusion of an 'enabled' leaf (type boolean) in the 'confederation' container is confusing. What is the purpose? There is no default configuration for a confederation that can be assumed if only the 'enabled' leaf is set to true and no other leafs in the container are set.

Hi,

This is an enhancement request to add following leafs in the "openconfig-if-aggregate.yang" module -

1. port-num
2. partner-port-num
3. mux-state
4. notification lacp-mux-state-change.

The latest YANG model is edited with these suggestions and attached with this Issue report.

Attachments:

1. Enhanced YANG model "openconfig-if-aggregate.yang"
   openconfig-if-aggregate.yang.txt
2. Diff of proposed enhanced model with the latest existing model.
   enhancement-diff.yang.txt

Regards,
Sushant

Hi,

Is it possible to rename sample-frequency to sample-interval?
This field is in milliseconds, and it defines time interval. Frequency is expressed in Hz, not in milliseconds.

Thanks,
Dmitry.

Hi,

When processing openconfig-bgp with latest revision of pyang from github, I get this error:

(pyang) ✔ /opt/git-repos/public/release/models/bgp [master|✔]
14:13 $ pyang --lint --strict -p ../policy openconfig-bgp.yang
openconfig-bgp.yang:428: error: restriction require-instance not allowed for this base type
(pyang) ✘-1 /opt/git-repos/public/release/models/bgp [master|✔]
14:13 $

Is this already a known issue?

Cheers,

Einar

Hi,

The "when" statement below is invalid. There is no "lag-type" leaf in the relative oc-path referred to by "when" statement.

module: openconfig-lacp

    container lacp {
      when "../config/lag-type = LACP" {
        description
          "LACP configuration and opstate is active when the
          aggregate interface type is LACP";
        }

Is the "when" statement intend to validate if at least one of the interfaces has lag-type as LACP configured? I don't think that is the intention, but if so, condition need to be modified appropriately. It is more likely a remnant from the openconfig-if-aggregate.yang module where lacp container used to reside.

Regards,
Sushant

Given the definition of the sequence-id for ACEs:

    leaf sequence-id {
      type uint32;
      description
        "The sequence id determines the order in which ACL entries
        are applied.  The sequence id must be unique for each entry
        in an ACL set.  Target devices should apply the ACL entry
        rules in the order determined by sequence id, rather than
        the relying only on order in the list.";
    }

Shouldn't this list definition use ordered-by system;?

    container acl-entries {
      description
        "Access list entries container";

      list acl-entry {
        key "sequence-id";
        ordered-by user;
        description
          "List of ACL entries comprising an ACL set";

Thanks!

Einar

Per #9, looks like the require-instance statements were removed for openconfig-bgp modules, but there are couple of other places where this still shows up. Any plans of removing these?

Shouldn't the output-frequency be in MHz?

grouping terminal-output-optical-frequency {
description
"Reusable leaves related to optical output power -- this is
typically configurable on line side and read-only on the
client-side";

leaf output-frequency {
  type uint64;
  units dBm;
  description

<<Magnus

Hello,

Thanks for the great work here!

I have a question regarding other type of entities of data. I am not entirely sure it makes sense, but I'd like to expose the idea and hear more thoughts.
I think many of us (including myself) struggled to synthesize commands such as traceroute, ping etc. whose output depends very much on the vendor.
Would make sense to you to have models for those outputs as well? They would be pretty much similar to oper in scope, but the trigger is an action running in background rather than exposing attributes.

I am looking forward to hearing your thoughts!
Thanks,
--Mircea

The current BGP model allows a route-distance to be set for EBGP routes and separate route-distance to be set for IBGP routes but there is no route-distance setting for all BGP routes (regardless of type) learned by a BGP instance. Would that be something to consider adding?

openconfig-mpls imports openconfig-segment-routing with a prefix of oc-sr
openconfig-mpls includes the sub-package openconfig-mpls-te which imports openconfig-mpls-sr whose prefix is also defined as oc-sr

In openconfig-mpls-sr, the prefix is defined as oc-mpls-sr

So can we please have the openconfig-mpls-te be modified to change the following
import openconfig-mpls-sr { prefix oc-sr; }
to
import openconfig-mpls-sr { prefix oc-mpls-sr; }

and the subsequent references of oc-sr to oc-mpls-sr?

In module openconfig-mpls-sr and couple other places, there are when statements which refer to the tunnel-type leaf, which is defined inside a sibling container or is a sibling node.

The relevant section of the pyang tree of this model looks like below:

         |     +--rw segment-routing
         |        +--rw tunnel
         |           +--rw config
         |           |  +--rw tunnel-type?   oc-mplst:tunnel-type
         |           +--ro state
         |           |  +--ro tunnel-type?   oc-mplst:tunnel-type
         |           +--rw p2p-lsp

         |     +--rw ldp!
         |     |  +--rw tunnel
         |     |     +--rw tunnel-type?   oc-mplst:tunnel-type
         |     |     +--rw ldp-type?      enumeration
         |     |     +--rw p2p-lsp
         |     |     |  +--rw fec-address*   inet:ip-prefix
         |     |     +--rw p2mp-lsp
         |     |     +--rw mp2mp-lsp

Currently, the when expressions in the above linked yang modules looks like below, which does not seem to make sense given the above tree:

container p2mp-lsp {
   when "tunnel-type = 'P2MP'" {

container mp2mp-lsp {
  when "tunnel-type = 'MP2MP'" {

container p2p-lsp {
  when "tunnel-type = 'P2P'" {

Should it be something like when "../tunnel-type in openconfig-ldp.yang and when "../config/tunnel-type in openconfig-sr.yang?

We have this identity:

  identity FORWARD {
    base ACL_ACTION_TYPE;
    description
      "Forwarding-related actions";
  }

And then this one:

  identity FORWARDING_ACTIONS {
    description
      "Base identity for forwarding-related actions";
  }

This is a bit confusing. Is there a typo here in the descriptions? Also, the names are very close.

Cheers,

Einar

https://github.com/openconfig/public/blob/master/release/models/policy/openconfig-routing-policy.yang#L188

leaf masklength-range {
type string {
pattern '^([0-9]+..[0-9]+)|exact$';

As per RFC 6020, the pattern string should follow the rules according to the XSD types(https://tools.ietf.org/html/rfc6020#page-119), according to which the '^' and '$' character is taken literally as part of the regex and not as an indication of head and tail.

So the ^ and $ needs to be removed from all instances of pattern string in openconfig yang modules.

I hope this it the correct forum to clarify a question I have with the openconfig-interfaces, leaf last-change.

leaf last-change {
  type yang:timeticks;
  description
    "Date and time of the last state change of the interface
    (e.g., up-to-down transition).   This corresponds to the
    ifLastChange object in the standard interface MIB.";
  reference
    "RFC 2863: The Interfaces Group MIB - ifLastChange";
}

The type yang:timeticks appears to not be the best choice based on the description. A yang:timeticks does not describe a date and time. Only the elapse time between an undefined reference epochs.
Furthermore, if using yang:timeticks, the leaf must define the reference epoch, which appears to be missing.

This leaf appears to be the same as
ietf-interface.yang : last-change :type yang:date-and-time

How are people in the community interpreting and using this leaf ?

In openconfig-vlan.yang in the vlan-top grouping there is a leafref inside vlans/vlan:

    leaf vlan-id {
      type leafref {
        path "/oc-vlan:vlans/oc-vlan:vlan/oc-vlan:config/" +
          "oc-vlan:vlan-id";
      }
      description "references the configured vlan-id";
    }

This leafref refers to a leaf further down the tree. The purpose of this leafref is to use the vlan-id in the config container as the key to the vlan list. However, this leafref constrains this vlan-id to be any vlan-id, it doesn't need to match the vlan-id inside its config container.

For example, this allows the following vlan collection members (in json syntax):

{ "vlan-id": 111,
  "config": {
    "vlan-id": 222 }
},
{ "vlan-id": 222,
  "config": {
    "vlan-id": 111 }
},

To me it seems this leafref's path should be:

path "../config/vlan-id";

to prevent the above example from being valid.

Would it be useful to add an add-paths container to each afi-safi list element so that Add-Paths behavior can be controlled per AFI/SAFI? Applying the same Add-Paths parameters to all supported address families seems too restrictive.

I downloaded latest version of yang models and compiled them with confdc and got some errors.

The augment path in openconfig-if-ethernet.yang is incorrect
Next problem is in openconfig-terminal-device.yang, the leafref path in logical-channel at line 457 and 473 seem to be wrong.
Seems like stuff is moved around and the paths are not updated accordingly.

Hi,

Could you please clearly define semantics of the out-octets and out-packets,

1. There is a mismatch in the description of out-octets and out-packets as of 2/20/2017. One refers to label imposed another to label imported;
2. Could you please explicitly mention whether statistics need to be collected for 'pop' label operation (or 'next' in SR terms),

A fragment of the model is shown for reference below.

Thanks,
Dmitry.

  leaf out-pkts {
    type yang:counter64;
    description
      "A cumulative counter of the total number of packets transmitted by
      the local system within the context which have a label imposed that
      corresponds to an Segment Identifier.";
  }

  leaf out-octets {
    type yang:counter64;
    description
      "A cumulative counter of the total bytes transmitted by the local
      system within the context which have a label imported that
      corresponds to an SR Segment Identifier.";

}

Why is allow-multiple-as modeled as specific to multipaths learned from EBGP peers? Why is not also applicable to multipaths learned from IBGP peers?

Looks like only an issue with openconfig-yang-types.yang. It contains a definition of date-and-time and the “pattern” looks incorrect according to RFC7950#section-6.1.3

Within a double-quoted string (enclosed within " "), a backslash
character introduces a representation of a special character, which
depends on the character that immediately follows the backslash:

\n      newline
\t      a tab character
\"      a double quote
\\      a single backslash

The pattern contains \ as the date separator. But entire pattern is enclosed in double quotes.

typedef date-and-time {
type string {
pattern
"^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}" +
"(.[0-9]+)?Z[+-][0-9]{2}:[0-9]{2}$";
}

Should the pattern be enclosed in single-quote or the instances of ‘\’ be changed to ‘\\’ to fix problem?.

The AFT and FIB models seem very similar. Is the AFT model intended to replace/deprecate the FIB model?

Hi,

leaf unnumbered (in the grouping subinterfaces-config) is referring to "/interfaces/subinterfaces/index", which is referring to
"/interfaces/subinterfaces/config/index", which is a leaf of type uint32.

leaf unnumbered has a default value "false", and it doesn't fit to uint32

Just wondering, do have any tools to validate the YANG models you published?

Thanks
Qing

default value for 'leaf unnumbered' under subinterfaces-config is mentioned as 'false' however leaf it is referring to has datatype as uint32'.

Refer to link:
https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-interfaces.yang#L691

Snippet:

leaf index {
type uint32;
default 0;
description
"The index of the subinterface, or logical interface number.
On systems with no support for subinterfaces, or not using
subinterfaces, this value should default to 0, i.e., the
default subinterface.";
}

leaf unnumbered {
  type leafref {
    path "../../index";
  }
  default false;    <== incorrect
  description
    "Indicates that the subinterface is unnumbered, and provides
    a reference to the subinterface that provides the IP
    address information (v4, v6 or both) for the current
    subinterface.";
}

I.e. the namespace for module openconfig-vlan should be:
namespace "http://openconfig.net/yang/vlan";

and the namespace for openconfig-vlan-types should be:
namespace "http://openconfig.net/yang/vlan-types";

At the moment they are the wrong way round.

This line:

https://github.com/openconfig/public/blob/master/release/models/ospf/openconfig-ospfv2-area-interface.yang#L153

...appears to have an illegal unicode character before the section number that causes a compilation failure in pyang:

      reference "RFC3630, §2.5.5";

Cheers,

Einar