public
public copied to clipboard
Add new model RPKI to router protocol to BGP global
Change Scope
- Proposing a yang model describing the RPKI to router protocol ( RFC 8210 and RFC 6810 ).
The proposed model defines groupings for connection, protocol and cache state. The model is rooted under
/network-instances/network-instance/protocols/protocol/bgp/global/
- This change is backward compatible.
module: openconfig-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw protocols
+--rw protocol* [identifier name]
+--rw bgp
+--rw global
+--rw rpki
+--rw caches
+--rw cache* [name]
+--rw name -> ../config/name
+--rw config
| +--rw name? string
+--ro state
| +--ro name? string
| +--ro cache-state? identityref
| +--ro host? oc-inet:host
| +--ro preference? uint8
| +--ro port? oc-inet:port-number
| +--ro ip4-roa-count? uint32
| +--ro ip6-roa-count? uint32
+--rw connection-data
| +--ro state
| +--ro transport-protocol? identityref
| +--ro last-update-sync-timestamp? oc-types:timeticks64
| +--ro last-full-sync-timestamp? oc-types:timeticks64
| +--ro last-serial-query-timestamp? oc-types:timeticks64
| +--ro last-reset-query-timestamp? oc-types:timeticks64
| +--ro last-config-change-timestamp? oc-types:timeticks64
| +--ro last-error-timestamp? oc-types:timeticks64
| +--ro last-connection-error-timestamp? oc-types:timeticks64
| +--ro last-connection-timestamp? oc-types:timeticks64
| +--ro error-reason? string
+--rw protocol
| +--ro state
| +--ro protocol? identityref
| +--ro refresh-interval? oc-types:timeticks64
| +--ro retry-interval? oc-types:timeticks64
| +--ro expire-interval? oc-types:timeticks64
| +--ro session-id? uint16
| +--ro serial-number? yang:counter32
+--rw pdu-counters
| +--rw received
| | +--ro state
| | +--ro serial-notify? yang:zero-based-counter64
| | +--ro cache-response? yang:zero-based-counter64
| | +--ro ipv4-prefix? yang:zero-based-counter64
| | +--ro ipv6-prefix? yang:zero-based-counter64
| | +--ro end-of-data? yang:zero-based-counter64
| | +--ro cache-reset? yang:zero-based-counter64
| +--rw sent
| +--ro state
| +--ro reset-query? yang:zero-based-counter64
| +--ro serial-query? yang:zero-based-counter64
+--rw pdu-error-counters
+--rw received
| +--ro state
| +--ro corrupt-data? yang:zero-based-counter64
| +--ro internal-error? yang:zero-based-counter64
| +--ro unsupported-protocol-version? yang:zero-based-counter64
| +--ro unsupported-pdu-type? yang:zero-based-counter64
| +--ro unexpected-protocol-version? yang:zero-based-counter64
| +--ro no-data-available? yang:zero-based-counter64
| +--ro invalid-request? yang:zero-based-counter64
+--rw sent
+--ro state
+--ro corrupt-data? yang:zero-based-counter64
+--ro internal-error? yang:zero-based-counter64
+--ro unsupported-protocol-version? yang:zero-based-counter64
+--ro unsupported-pdu-type? yang:zero-based-counter64
+--ro unexpected-protocol-version? yang:zero-based-counter64
+--ro withdrawal-unknown-record? yang:zero-based-counter64
+--ro duplicate-announcement-received? yang:zero-based-counter64
Platform Implementations
- Arista: Implementation
Major YANG version changes in commit 12d3415ba53d504c2ba1a1dc3bf4bf511af4361f:
Compatibility Report for commit 12d3415ba53d504c2ba1a1dc3bf4bf511af4361f: ✅ pyangbind@8849be8
@SteliosPapoutsakis are you still interested in pursuing this pull request? Let me know and I will give it a review.
Hi @dplore. Yes, we are still interested in a review
As a quick note, there's a few pieces of external overlapping work that might be useful to defer commit until there's been a bit of discussion:
- Juniper has an internal RPKI modeling effort that had been underway for a bit.
- There's also some IETF work that overlaps: https://datatracker.ietf.org/doc/draft-liu-sidrops-rtr-yang/03/.
I've started a dialog with the authors of the IETF work wearing my IETF IDR chair hat and as a Juniper developer. There's some goodness that would come out of coordinating the various ongoing projects. A Juniper developer will likely provide some detailed comments vs. this PR soon to cover our gap analysis vs. our internal proposal as discussion points. We can either iterate here in github or also coordinate via email.
The goal is to reconcile the state present in each of the models and some high level skeleton points for indexing to make sure we don't have unnecessary clashes in the implementations of each of these models.
The IETF and OC model will certainly have differences due to the structural ways IETF and OC like to do things - that's expected. But we can at least harmonize the general indexing where we can, and make sure the state is in agreement.
We don't have a current need for this model anymore and we have decided to drop this pull request