Update openconfig-network-instance-l3.yang to change alarm-threshold value

[shasingh27]

Update openconfig-network-instance-l3.yang to change alarm-threshold value from absolute to percentage

I have taken a look at JUNOS implementation and it is percentage there.

I also checked other implementations Took a look at Arista EOS and they support the following...

a1(config-router-bgp)#neighbor 1.1.1.1 maximum-routes 10 warning-limit ? <0-4294967294 Maximum number of routes after which a warning is issued (0 means never warn) <1-100 Percentage of maximum number of routes at which to warn ( 1-100 )

——————————————— I think Cisco’s implementation also takes threshold as percentage. I could find following document for bgp maximum-prefix feature.   https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/b-ncs5500-bgp-cli-reference/b-ncs5500-bgp-cli-reference_chapter_01.html#wp6592192440

And for nokia sros/srlinux https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/BGP-CLI.html#1124424   As threshold is relative to the configured max, I think it makes sense to be a % value rather than an absolute value.

[Note: Please fill out the following template for your pull request. lines tagged with "Note" can be removed from the template.]

[Note: Before this PR can be reviewed please agree to the CLA covering this repo. Please also review the contribution guide - https://github.com/openconfig/public/blob/master/doc/external-contributions-guide.md]

Change Scope

• [Please briefly describe the change that is being made to the models.] Update openconfig-network-instance-l3.yang to change alarm-threshold value from absolute to percentage

• [Please indicate whether this change is backwards compatible.] It is not backward compatible

Platform Implementations

• Implementation A: link to documentation and/or implementation output.
• Implementation B: link to documentation and/or implementation output.

[Note: Please provide at least two references to implementations which are relevant to the model changes proposed. Each implementation should be from separate organizations.].

[Note: If the feature being proposed is new - and something that is being proposed as an enhancement to device functionality, it is sufficient to have reviewers from the producers of two different implementations].