Advanced Network Topology Discovery Proposal for TFS Controller

Proposal of new features for TFS TFS TECHDAYS #2 Oscar Gonz lez de Dios, Pablo Armingol

BGP-LS Speaker Component Network device inventory management Multivendor Support for Openconfig Driver Agenda 2

BGP-LS Speaker Component: Motivation Currently, the IP/MPLS topology (nodes, links, information of the links) is not auto-discovered and needs to be described to TFS. Proposal: Implementation of a topology module to retrieve topological information from an IP/MPLS network via BGP-LS and incorporate it in TFS controller. The module will contain a BGP-LS speaker that will connect to remote BGP-LS speakers enabled in the network and read the Update messages sent by them. The information about nodes and links read from update messages from remote BGP-LS speakers will be incorporated in TFS Context database. This way, the controller will maintain a real time view of the IP/MPLS network topology in terms of nodes and links. The proposal is to have a first version obtaining basic information (to be detailed here) and increase the support of detailed nodes and link information in subsequent features. The basic information required is: Nodes: Node name, router-id Links: Source node, destination node. Future versions will consider detailed Traffic Enginnering and Segment routing information that will be documented in specific feature requests. Exporting the information will be considered in a separated feature. The network scenario that is consider in this use case is an IP/MPLS network in which every router participates in one or more IGP processes. BGP-LS Speakers are placed in the routers to export the topology to the TFS Controller. (TID) New BGP-LS Speaker component (#40) Issues TFS / controller GitLab (etsi.org) 3

BGP-LS Speaker Component: Definition of done Clarifications to Expected Behavior Changes TFS controller is able to establish BGP-LS connection with remote BGP-LS speakers from at least 2 different vendor implementations A node withdrawn Update is received indicating this node is no longer available TFS controller is able to read link and node updates Mark the node as "down" in the Context database Via WebUI, the TFS user can delete nodes that have been down for a long time TFS incorporates new links in context database TFS shows new discovered nodes via GUI New tab "Topology" to manage the new module It should be possible to create topologies from the "Topology" tab 4

BGP-LS Speaker Component : component impact The remote BGP-LS speakers are configured in at least one router of each IGP domain that wants to be discovered The Context data model and database structure needs to be elaborated The autonomous system is configured in each remote BGP-LS speaker announcing updates A unique instance ID is configured for each IGP domain Webui must provide interaction with the user to configure the speaker and add new discovered devices. When multiple BGP-LS speakers announce the same IGP domain nodes and links, the instance ID is the same The network nodes HAVE a unique name and unique router id configured within their domain 5

Network device inventory management: Motivation Currently, the inventory data is not auto-discovered and needs to be described to TFS. Proposal: The proposed functionality is to retrieve the hardware inventory from the network devices, store the information in TFS Controller, and expose it via RestConf API using standard Yang based data model. TFS will retrieves the list of components of each device using Netconf and OpenConfig data model via the device driver. Hardware components to retrieve: CHASSIS: is the top-level component and can be understood as the main device CPU: processing unit, e.g., a management processor FAN: cooling fan or some other heat-reduction component POWER_SUPPLY: component that is supplying power to the device FABRIC: interconnect between ingress and egress ports on the device CONTROLLER_CARD: a type of card whose primary role is management or control rather than data forwarding LINECARD: component typically inserted into a chassis slot that provides interfaces to the network FRU: replaceable hardware component PORT: physical port, e.g., for attaching pluggables and networking cables TRANSCEIVER: pluggable module present in a port (TID) Network device inventory management (#41) Issues TFS / controller GitLab (etsi.org) 6

Network device inventory management: Common information Type of component as identified by the system Unique identifier assigned by TFS for such component description: System-supplied description of the component location: System-supplied description of the location of the component within the system mfg-name: System-supplied identifier for the manufacturer of the component mfg-date : System-supplied representation of the component'smanufacturing date 7

Network device inventory management: component impact The network nodes that are The Context data model needs to Update to acomodate a list of components per device part of the inventory have NetConf enabled and support OpenConfig platform model Each component, uniquely identified by an uuid will be be stored in the database The network nodes are already onboarded in TFS and The device component needs to collect the openconfig-platform information and send it to context upon request are already associated to the openconfig driver 8

Multivendor Support for Openconfig Driver: Motivation Motivation: Different vendors and O.S. versions support different versions of Openconfig Yang model Proprietary rules and deviations apply, making configuration challenging Proposed Solution: Identify new device by vendor and O.S. version Create classes that implement different versions of the Yang model Make adjustments in the existing methods in the device driver to cover mandatory fields, specific naming conventions, vendor augmented fields, and specific field values Keep input to the device driver vendor agnostic Scope: Focus on existing services (ACLs, L3 VPNs, and L2 VPNs) Expect new services to follow this approach (TID) New feature: Multivendor Support for Openconfig Driver (#43) Issues TFS / controller GitLab (etsi.org) 9

Multivendor Support for Openconfig Driver : component impact The exact versions of the Openconfig Yang model are known in advance A new field from each added OpenConfig device must be processed TFS has saved the corresponding yang model for the version of each device to be configured Change template generation to create dynamic templates with Pyangbind adapted to the specific Openconfig Yang model version and specific vendor requirements when needed TFS will not dynamically update the support of new versions 10