Summary

  • Rob Shakir is a named author on nine RFCs in the current IETF Datatracker record. The relevant documents span routing requirements, resiliency use cases, the Segment Routing Architecture, the MPLS data plane, and OSPF extensions. That record supports a history of collaborative standards work. It does not support a claim that he invented Segment Routing, OpenConfig, YANG, or vendor-neutral network management. [1]
  • His OpenConfig work makes a different contribution visible. Network-instance and route-redistribution documents try to describe forwarding tables, switching contexts, and movement of routes in a way that can map to devices built by different vendors. The design is useful precisely because the devices are not identical. A common model does not erase those differences; it gives operators a shared place to state intent and receive an explicit rejection when a platform cannot support it. [7] [8] [9]
  • The strongest decision pattern is fail-closed description. OpenConfig's redistribution guidance says that if neither a specific import policy nor a default import policy exists, routes should not be redistributed. RFC 8402 likewise states trust-boundary and filtering requirements for explicit segment information. In both cases, the shared description is valuable because it defines what must not happen as well as what may happen. [4] [8]
  • The work also contains a visible handoff. Early network-model drafts associated with Shakir expired, while a current IETF BGP YANG model continues under a different author group and remains work in progress. That is not proof that every early design survived. It is evidence that infrastructure knowledge can move beyond its original contributors and remain open to revision. [1] [9] [10] [11] [12]

The result is a person-level story about operational continuity, not celebrity. Shakir's contribution can be located in documents that other people can read, implement, reject, revise, and inherit. The limits are equally public: a model cannot guarantee vendor behavior, a standard cannot prove deployment, and a route description cannot decide policy for an independent operator.

The trouble begins when two correct routers disagree about words

Imagine a network with routers from two manufacturers. Both devices can hold a table of destinations. Both can learn routes from BGP, the protocol through which independently run networks tell one another which Internet addresses they can reach. Both can place a customer in a separate virtual routing context. At the level of traffic, the devices may perform comparable jobs.

At the level of management, however, they may expose those jobs differently. One system may place a setting under an interface. Another may place it under a virtual routing instance. One may keep a separate table for every routing protocol. Another may put routes learned from several protocols into a shared table. One may return a structured error when asked for an unsupported function. Another may accept the request but interpret it through a vendor-specific convention.

An engineer working manually can learn those differences. A team can keep separate runbooks and use separate commands. The difficulty grows when the network must be automated, audited, or handed to another group. A program cannot rely on a human remembering that the word used on router A has a slightly different scope on router B. It needs a stable description of intent and state. That description has to be precise enough to avoid moving traffic by accident, yet broad enough to map onto devices that were not designed from the same internal blueprint.

This is where data models enter the story. A data model is not the configuration itself. It is a structured vocabulary for saying what a network element contains and what an operator wants it to do. In the YANG modeling language used by many network-management systems, the vocabulary is arranged as a tree. An automation system can address a path in that tree, set a value, or read operational state. The hope is that a shared tree lets software work across multiple platforms without rewriting every task around a different command-line interface.

The phrase "vendor neutral" can make the result sound more complete than it is. Neutrality does not mean that hardware capabilities become identical. It means the model is not supposed to reproduce the private hierarchy of one vendor as the only legitimate way to describe the network. The model still has to confront differences in forwarding chips, protocol support, table structure, and error behavior. A platform may be unable to perform an otherwise valid modeled request.

The public documents associated with Shakir are unusually useful because they do not hide that problem. The OpenConfig network-instance use cases cover flat switches, provider-edge routers, and hybrid devices rather than pretending that every box has one internal structure. The page even discusses how a device should respond when a flexible model allows a request that its hardware cannot perform: in the described case, the implementation should reject the request rather than claim support through a silent deviation. [7]

That rejection is not a failure of the common model. It is an important output. An explicit "no" gives the operator a fact that can be logged, tested, and handled. Silent reinterpretation creates a more dangerous condition: the automation appears to succeed while the device does something else. The difference is the same one that separates an accurate registry record from a ceremonial form. The value lies in whether the record matches what the running system can actually do.

Shakir's documented role in this work is bounded. The OpenConfig page credits "Rob Shakir & OpenConfig WG members" as contributors. The wording matters. It supports participation in a collective model and its explanation. It does not establish that he alone determined the structure, that he implemented it on every platform, or that operators adopted it in a uniform way. The person-level contribution is visible in authorship and contribution records; the operating result remains distributed among working-group participants, implementers, vendors, and network teams.

A network instance is a boundary before it is a feature

The 2015 OpenConfig network-instance Internet-Draft provides an early, dated view of the design problem. It describes a generic construct that can contain Layer 3 routing entries, Layer 2 forwarding entries, or both. In ordinary terms, a network instance is a named forwarding world inside a device. It can represent the main routing table, a customer's private routing context, a switched service, or a combination that a particular platform supports. [9]

The draft states that the model was deliberately shaped around service-provider equipment and discussions among OpenConfig members. That admission is useful. A model is never created from nowhere. It reflects the networks its contributors know, the devices they need to manage, and the failures they are trying to avoid. Calling the construct generic does not make it universal. It means the authors sought a level of description that could cover several common forms without fixing the structure to one device family.

The later OpenConfig use-case document tests that abstraction against different device types. A simple Layer 2 switch may need one global VLAN space. A provider-edge router may terminate different services on subinterfaces and place them into separate forwarding contexts. A hybrid device may switch some traffic in a global context while routing other traffic through a private instance. The model places those variations around a shared idea: interfaces or subinterfaces are associated with a network instance, and the instance holds the forwarding context relevant to them. [7]

For a non-specialist, the closest analogy is a building with rooms that have different access rules. A physical door can lead into one room or another, and each room can contain its own directory of destinations. The model should let the operator name the rooms and connect the doors without assuming that every building has the same internal walls. It also has to avoid opening a passage merely because two rooms happen to exist.

That last point becomes crucial when routes move between tables. Networks often run several routing protocols or maintain several routing contexts. A route learned in one place may need to be made visible in another. This is called route redistribution. It can be necessary, but it is also a way to create loops, expose routes to the wrong service, or turn a local path into a wider announcement.

The OpenConfig route-redistribution document starts from a concrete vendor difference. Some systems treat each protocol as having its own routing information base. Others allow several protocols to feed a common table. A shared model cannot simply copy one of those designs and call the other incorrect. It uses explicit connections between tables to express which routes may move and under what policy. [8]

The most important sentence in that document is not about convenience. It states that when an import policy is absent and no default import policy is present, no routes should be redistributed. [8] In other words, the model's safe meaning is not "move everything unless told otherwise." It is "move nothing until an operator has supplied a rule."

That is a decision about operational responsibility. The model does not decide which routes are legitimate for every network. It requires the local operator to make that decision explicitly. A shared language records the choice; it does not replace the authority of the network running the device. This is a practical form of decentralization. Each operator retains control, while the structure of the choice becomes visible enough for software and people to inspect.

Shakir is credited as the contributor on the route-redistribution page. Again, the evidence supports a specific role in a project document, not a claim that he created route redistribution or personally chose policy for deployed networks. The page's value lies in the reasoning it preserves. Different implementations exist. The model must map to both. Movement between tables needs an explicit connection. Missing policy should close the path rather than open it.

These rules make the model useful during handoffs. A new team can inspect the table connection and the policy associated with it. An auditor can ask whether a route crossed a boundary because a rule permitted it or because a device default was misunderstood. An automation system can compare intended configuration with returned state. None of this guarantees that the implementation is correct. It creates a record against which the implementation can be tested.

Common models matter most when they reveal disagreement

Network automation is often described as a way to make changes faster. Speed is only one part of the value, and it can become a liability when the description underneath is ambiguous. A fast system can reproduce the same mistake across hundreds of devices before a person notices.

A common model creates several opportunities to stop that propagation. It can define types and ranges so an invalid value is rejected. It can separate intended configuration from observed operational state. It can require a policy reference before routes move between tables. It can return a structured error when a platform cannot support a request. It can let a test compare the same path across two vendors even when their command lines are unrelated.

Those controls depend on honest mapping. A vendor has to translate the shared model into its own implementation. An operator has to decide which parts of the model are safe to use. Tooling has to handle rejected requests and partial support. If any layer treats the model as a marketing checkbox, apparent consistency can conceal real differences.

The OpenConfig network-instance page acknowledges this by refusing to make the model overly prescriptive about individual switching capabilities. [7] That choice has a tradeoff. Flexibility lets one structure cover more hardware, but it also permits requests that a particular device cannot execute. The proposed answer is explicit rejection. The model does not guarantee capability; it creates a disciplined way to ask and to learn that the answer is no.

This is more than an implementation detail. It defines what an accurate operational record looks like. A configuration database that says a feature is active when the device ignored it is worse than an incomplete database. It gives the next engineer false confidence. The same applies to state telemetry. A field that exists in a schema but is not populated correctly can mislead an incident-response system.

Shakir's early work on the gRPC Network Management Interface, or gNMI, belongs to this same boundary. A March 2017 archived draft lists him with Anees Shaikh, Paul Borman, Marcus Hines, and Carl Lebsack. It describes an early interface for retrieving and modifying network configuration and state using structured paths and messages. [10] The draft is not a current standard, and it should not be presented as one. Its place in the chronology is narrower: contributors were working on a transport and operation surface through which shared models could become usable by software.

The distinction between a model and an interface matters. A model says what the data means and how it is arranged. An interface says how a client asks for the data or sends a change. A complete automation system needs both, plus authentication, authorization, implementation, testing, and rollback. No single document supplies that whole system.

The Datatracker now lists the OpenConfig gNMI, network-instance, operational-state, model-catalog, and model-structure drafts among Shakir's expired Internet-Drafts. [1] "Expired" is not a synonym for "worthless." Internet-Drafts are temporary working documents. They may be revised, replaced, moved to another publication venue, or abandoned. Their expired status prevents a responsible writer from calling them current standards. It also leaves a public trail of the questions contributors were trying to solve.

That trail is useful because network management tends to hide inside products. A command may work, but the public cannot see why a vendor chose its hierarchy or how another implementation differs. Open drafts and project documents expose at least part of the design argument. They allow later contributors to reuse, reject, or reframe the work. The record becomes transferable even when the document does not become an RFC under the same title.

Segment Routing moved the question from device state to path expression

The OpenConfig work deals with how devices expose configuration and state. Shakir's RFC record also reaches into how paths are expressed inside a routing domain. The IETF Datatracker lists him among the authors of RFC 7855, the 2016 problem statement and requirements for Source Packet Routing in Networking; RFC 8355, the 2018 resiliency use cases; RFC 8402, the 2018 Segment Routing Architecture; RFC 8660, the 2019 MPLS data-plane specification; and RFC 8665, the 2019 OSPF extensions for Segment Routing. [1] [2] [3] [4] [5] [6]

Segment routing can sound abstract, but its central idea is approachable. Traditional traffic-engineering systems may keep path-related state at many points inside a network. Segment routing lets an ingress node express an ordered list of instructions, called segments, that guide a packet through the domain. Depending on the data plane, those instructions can be represented using MPLS labels or IPv6 segment identifiers. The network still needs routing protocols, topology information, policy, and correctly configured devices. Segment routing changes where some path intent is expressed; it does not remove operational responsibility.

RFC 8402 is collective work. Its author list includes Clarence Filsfils, Stefano Previdi, Les Ginsberg, Bruno Decraene, Stephane Litkowski, and Rob Shakir, and it names additional contributors and reviewers. [4] That structure is part of the evidence. An architecture used across independent implementations is not credible as the private idea of one person. It has to survive review, protocol interaction, security analysis, and the different assumptions of operators and vendors.

The architecture also demonstrates why a shared description must include boundaries. RFC 8402 says that routers at the edge of a segment-routing domain must filter external traffic aimed at labels associated with segments inside the trusted domain. It states that explicit-routing information must not leak beyond the administered domain by default. [4] These are not decorative security notes. A segment list can influence where packets go. If untrusted traffic can impose internal instructions, the same mechanism that gives an operator control can give an outsider an unwanted form of control.

This boundary is similar to the route-redistribution default. In both cases, useful information must not cross from one context to another merely because the mechanism exists. An import policy authorizes routes to move between tables. A domain boundary controls whether external traffic can use internal segment instructions. The standard or model describes the gate, while the operator remains responsible for implementing it.

RFC 8660 and RFC 8665 show how an architecture becomes more specific. One explains operation with the MPLS data plane. The other defines OSPF extensions that advertise segment-routing information. [5] [6] The architecture alone does not make a router interoperable. Protocols need encodings, advertisements, and error behavior that independent implementations can follow. Each additional document narrows ambiguity, while also creating another place where an implementation can be incomplete or wrong.

Shakir's contribution is visible through co-authorship across these layers. The record does not show him as the sole designer, nor does it show which paragraph originated with which person. It supports a more useful claim: he participated in a body of collaborative work that connected problem statements, resiliency questions, architecture, and protocol-specific details.

It is tempting to turn that sequence into an adoption story. The sources in this article do not permit one. They do not count production deployments, compare outage rates, or identify private networks whose reliability improved because of a particular text. Standards Track status means the document passed an IETF process; it does not mean every vendor implemented it or every operator enabled it correctly. The public result is the specification and its stated boundaries.

Resiliency is a set of choices, not a victory claim

RFC 8355 is especially valuable because it describes resiliency as a set of use cases rather than as a guaranteed property. The document considers path protection, management-free and managed local protection, loop avoidance, and the coexistence of multiple protection techniques. [3]

Those categories describe different places where a network can prepare for failure. A local repair may let a nearby router move traffic around a failed link without waiting for a central controller. A managed approach may install a specifically planned bypass. A network may combine methods, but the interaction can create complexity. Loop avoidance matters because a repair that sends traffic back toward the failure can make the situation worse.

For a public profile, the important fact is not that Shakir and the other authors "made networks resilient." The RFC cannot prove that. The supported fact is that they documented use cases and constraints for protection in a segment-routing setting. The difference protects both technical accuracy and attribution. Equipment vendors implement mechanisms. Operators choose designs and thresholds. Network teams test failure behavior. Traffic outcomes depend on topology, configuration, software, and the actual incident.

The same caution applies to management-free protection. The name can suggest that management is no longer needed. In context, it describes a repair method that does not require a preconfigured bypass for every protected resource. It does not mean the network requires no planning, monitoring, or policy. An automated local response still depends on correctly distributed topology and segment information. It has to coexist with the rest of the forwarding system.

This is a recurring lesson in Shakir's record. Abstraction is useful when it removes repetitive, vendor-specific work. It becomes dangerous when the operator mistakes abstraction for absence of responsibility. A model can express the same request to several devices, but someone must verify how each device maps it. A segment list can express a path, but someone must secure the domain boundary. A resiliency mechanism can react quickly, but someone must test whether it reacts to the right failure.

Public standards make those obligations inspectable. Security and manageability considerations sit in the same document as the attractive capability. Alternatives and coexistence problems are named. Authors and contributors are listed. The record does not guarantee good operations, but it gives operators a common document against which to review an implementation or a design.

That is why failures and limitations should not be removed from a person profile. They are not minor disclaimers after a success story. They identify the actual work. Describing an operational system means specifying how it refuses unsafe input, how it behaves when capability is absent, how it separates trusted from untrusted contexts, and how it transfers responsibility to the operator at the right point.

An expired draft can still show a successful handoff

Standards work is often narrated as a straight line: an individual has an idea, writes a document, and the document becomes a standard. The records around network models are less tidy and more instructive.

The 2015 network-instance draft names Shakir as author and has expired. [9] The 2017 gNMI draft lists five authors and has also expired. [10] His Datatracker page contains dozens of expired drafts and, at the checked date, no active Internet-Drafts. [1] If publication status were the only measure, that history would look like a long list of unfinished work.

Yet the underlying subjects did not disappear. OpenConfig maintains current project documentation for network instances and route redistribution. [7] [8] The IETF continues to work on a vendor-neutral BGP YANG model covering configuration, policy, and operational state. The checked June 2026 version states that it is intended for heterogeneous environments and should map to existing implementations across multiple vendors. [11]

The current BGP model does not list Shakir among its current authors. Its history, however, preserves earlier author and posting-confirmation records that include him along with other contributors. [12] That creates a useful boundary. It would be inaccurate to call the current draft "Shakir's BGP model." It is also incomplete to pretend the earlier lineage never existed.

The more interesting story is transfer. A model intended for operational use should not depend on the permanent presence of its first authors. Requirements change. Working groups find gaps. New protocol extensions appear. Reviewers identify security or modeling problems. Implementers discover that a structure maps poorly to real devices. Other authors take responsibility for the next version.

The current draft remains an Internet-Draft, not a finished standard. It may change, be replaced, or expire. [11] That uncertainty is part of the public record. It prevents the handoff from being described as a completed victory. At the same time, the continuation of the work under new authors shows that the problem was not trapped inside one person's private tooling.

This is operational continuity at the documentation layer. The names, versions, and histories let later readers reconstruct how a model moved. An expired draft supplies a dated design. A project page supplies current use cases. A working-group document supplies the present standardization state. None is sovereign over deployed networks. Together they form a record that implementers and operators can compare with running code.

Shakir's person-level contribution is strongest when described in those terms. He appears in early drafts and in collaborative RFC author lists. Later maintainers and authors carry related work forward. The evidence does not reveal every editorial decision or line of text. It does show that his work entered public processes that could continue without preserving his name at the top of every current document.

That is a more durable form of influence than permanent ownership. It is also easier to verify. A reader does not have to accept a claim about personal vision. The versions, author lists, and current documents are visible. The gaps and changes are visible too.

What a shared model cannot make the same

The strongest argument for a common model is also the source of its main risk. Operators want one way to describe a function across different devices because the devices are different. If the devices were identical, the abstraction would be unnecessary. If the abstraction hides too much difference, it can make automation appear more reliable than the equipment beneath it.

Hardware may expose capabilities at different levels. One platform may support a requested combination of switching and routing tables; another may not. One may provide detailed operational state; another may return only part of it. One may apply a change transactionally; another may pass through an intermediate state. A shared schema can name the intended result, but it cannot manufacture missing silicon, software, or rollback behavior.

The OpenConfig network-instance documentation handles one version of this problem through explicit rejection. [7] That is necessary but not sufficient. Clients must treat the rejection as a real gate. Monitoring must alert on it. Change systems must avoid marking the entire job successful because most devices accepted the request. Engineers need a way to understand whether the unsupported function is optional, required, or dangerous to approximate.

Even a successful response can be ambiguous. A device might accept configuration but expose state after a delay. It might normalize a value. It might map a shared field onto a vendor mechanism with different edge cases. This is why model validation has to reach the running system. A configuration record alone is not proof that traffic follows the intended path.

Segment routing has a parallel limit. A shared architecture and protocol extensions let devices exchange and interpret segment information. They do not choose a safe policy for every network. The operator defines the trusted domain, filters its boundaries, controls who may impose paths, and decides how to respond when topology or protocol state changes. RFC 8402 states requirements, but a requirement on paper becomes protection only through implementation and operation. [4]

Resiliency mechanisms also interact with physical reality. A backup path described in a control system may share a conduit, power source, or device with the primary path. A local repair may preserve forwarding while sending traffic through a congested link. A model can expose identifiers and policy; it cannot prove that two paths are physically independent without other evidence.

The current BGP YANG draft carries another limit: breadth. It seeks to cover commonly deployed BGP features, policy hooks, and operational state while remaining extensible. [11] The more features it covers, the harder it becomes to ensure that every implementation interprets every field consistently. The document itself remains under review. Its unfinished state is not an embarrassment. It is a warning against treating the word "standard" as a substitute for testing.

These limits keep the story grounded. Shakir's contribution to shared descriptions matters because heterogeneous networks are difficult to operate. It does not make heterogeneity disappear. The models and architectures create public contracts: names, types, relationships, defaults, and boundaries that implementations can be tested against. The test still has to happen.

Attribution is part of the technical architecture

The documents in this record distribute credit with unusual precision. RFC 8402 names six authors and additional contributors. RFC 8355 names four authors and acknowledges another contributor. The OpenConfig page credits Shakir with working-group members. The gNMI draft names five authors. The current BGP YANG draft has a different active author group from the earlier lineage. [3] [4] [7] [10] [11] [12]

Those lists are not ceremonial. They tell the reader that the work crossed organizational and personal boundaries. A routing architecture has to interact with existing protocols. A data model has to reflect operators and implementations. A management interface has to support clients and servers. Review and maintenance alter the result after an early author has moved on.

Removing that distribution would weaken the technical account. If Shakir were presented as the lone creator, the story would imply that shared network infrastructure emerged from individual authority. The source record shows the opposite. Public drafts, working groups, contributors, reviewers, implementers, and later authors make the description usable beyond one person's environment.

Precise attribution also protects against a common kind of biography inflation. A person's name on an RFC proves authorship of the document in the IETF record. It does not prove that the person wrote every section, originated every idea, implemented every feature, or caused every later deployment. A contributor credit proves a documented contribution; it does not reveal private labor division. An author address records an affiliation at the time of publication; it should not be converted into a current job without current evidence.

For Shakir, the safest and most informative claims are therefore visible ones. The IETF Datatracker associates him with nine RFCs. [1] Selected RFCs name him among collective author groups for Segment Routing requirements, resiliency, architecture, MPLS, and OSPF work. [2] [3] [4] [5] [6] OpenConfig pages credit him on network-instance and redistribution material. [7] [8] Archived drafts record early work on network instances and gNMI. [9] [10] The current BGP model continues under different authors while its history preserves earlier participation. [11] [12]

That sequence supports a clear contribution: helping turn operator problems into public structures that others could refine and implement. It does not require a claim about personality, private intention, or heroism. The documents carry the case.

The durable result is a record that can meet running systems

A network is operated through two kinds of reality. One is physical and executable: packets move, links fail, devices accept or reject commands, and routing tables change. The other is descriptive: inventories, models, policies, standards, and diagrams say what the system is supposed to contain and do.

Neither layer is sufficient alone. Running code without an accurate description becomes difficult to audit and hand over. Documentation without a running-system check can drift into fiction. The work associated with Shakir sits where the two have to meet.

A network-instance model describes forwarding contexts in terms that several kinds of device can attempt to implement. Route-redistribution guidance records a policy boundary and closes it when authorization is absent. gNMI work addresses how software asks for modeled configuration and state. Segment Routing RFCs describe how path instructions and protocol extensions fit together, while stating trust and filtering boundaries. Resiliency use cases expose choices without promising results. Draft histories show how the descriptions move to later maintainers.

The result is not a universal control plane. Independent networks still choose their vendors, policies, models, and deployment pace. Standards organizations do not operate their routes. Model repositories do not decide which traffic a network should accept. The value is coordination without pretending that coordination is ownership.

For operators, that value appears in ordinary moments. A replacement router can be compared with the state expected by automation. A rejected configuration can stop a change before traffic moves. A table connection can show why a route entered another context. A boundary rule can prevent outside traffic from using internal segment instructions. A new team can read the version history and see that a current model has different maintainers from an old draft.

None of these moments proves that the overall system is safe. Each creates a piece of evidence. The pieces can be checked against devices, route collectors, change records, and incidents. When they disagree, the disagreement is visible enough to investigate.

That is the central limit and the central achievement of Shakir's documented work. Shared models and standards cannot force reality to conform. They can make claims about network state specific enough to test. They can state what must be rejected, what must remain inside a trust boundary, and where local policy begins. They can preserve authorship and change history so the description survives a handoff.

The most important unresolved question is therefore not whether one model will finally make every router look the same. It is whether operators, implementers, and standards groups will keep the shared description close enough to running behavior that a difference becomes evidence rather than surprise. Shakir's public record does not answer that question for the Internet. It shows the kind of work required to keep asking it accurately.

Sources

  1. IETF Datatracker, Profile for Rob Shakir.
  2. RFC Editor, RFC 7855: Source Packet Routing in Networking Problem Statement and Requirements.
  3. RFC Editor, RFC 8355: Resiliency Use Cases in SPRING Networks.
  4. RFC Editor, RFC 8402: Segment Routing Architecture.
  5. RFC Editor, RFC 8660: Segment Routing with the MPLS Data Plane.
  6. RFC Editor, RFC 8665: OSPF Extensions for Segment Routing.
  7. OpenConfig, Network instance use cases.
  8. OpenConfig, Route redistribution in network instances.
  9. IETF Datatracker, draft-openconfig-rtgwg-network-instance-01.
  10. IETF Datatracker, draft-openconfig-rtgwg-gnmi-spec-00.
  11. IETF Datatracker, current YANG Model for BGP-4.
  12. IETF Datatracker, history for the BGP model draft.