Planned Revision Support - Washington Release Network Inventory

Grace Petrucci
ServiceNow Employee
ServiceNow Employee

on ‎02-19-2024 12:52 PM

Planned Revision Support Overview

Network planning is critical in be able to work with a complete and accurate network inventory view to be able to reduce CAPEX and ensure that service providers are maximizing their ROI by increasing their inventory utilization. Planned revision support with network inventory enables inventory agents and managers to  easily implement changes that need to be made to an operational network element. Planning and implementing changes to existing inventory elements can be fulfilled in three simplified steps:

  1. Plan changes to existing inventory elements. As part of the planning phase, inventory agents now have the capability to create new revision where changes can be made for inventory planning purposes, approval processes, budgeting requirements and requirement validation as examples of ongoing activities.
  2. Implement desired changes. Once the planning phase is complete, the new revision can now be placed in production.
  3. Update Network Inventory with the latest revised changes. Finalizing the desired changes to ensure that all planned revisions that are in production are captured within network inventory.  

Picture1.png

 

Implementation Details of Planned Revision Support within Network Inventory

Planned revision support enables Inventory Agents and Inventory Managers to make updates to a live connection element which would include:

  • Connection Element: The foundational structure (underlay hierarchy) needed for a connection to operate.
  • Impactful Attribute: These include attributes that are critical to the implementation of network inventory, for instance bandwidth.

When managing a network workload distribution, it becomes necessary to implement the capability to create revisions of existing inventory to be able to manage the complete network lifecycle as customer requirements or SLAs. Some use cases would include:

Network Planning: As part of capacity planning, planned revision can help to provide insights into making changes and capacity improvements to an existing inventory element.

Service Assurance:  planned revision support may help to identify and make the necessary network changes to investigate ongoing cases or to implement changes required with a root cause analysis (RCA).

Design Changes for Planned Revision Support 

The implementation of planned revision for a connection element within Network Inventory requires the implementation of two major design elements listed below:

  1. Creation of a Clone CI: This involves generating a duplicate of an operational CI that requires modification.
  2. Operationalization: Once the design has been implemented within the network, the end user would seek to combine the two created CIs to ensure that the most recent data, including attributes and connection elements, are present.

The Washington release of Network Inventory includes the implementation of the following sceanarios:

  • Addition of a connection element to an already operational connection.
    • For instance, increase the capacity of the connection by adding additional routes to the underlying connectivity – i.e. adding a member to a LAG
  • Removal of a connection element from an existing operational connection.
    • For instance, removing a member from LAG
  • Adjustment of significant Attribute values.
    • For instance, increasing/decreasing port speed, bandwidth etc.
  • Modification of the in end points of a connection.

In the following sections describes the ServiceNow implementation of the below diagram in which  a LAG member is added to the planned revision. This example will be adding an additional ENET 3 that consists of Physical Connection 7,8,9 (PH7, PH8, PH9) to the LAG1’. LAG1’ will then include all the components of LAG1 (ENET1 and ENET2) along with the additional ENET3 which will increase the capacity of existing LAG1. In the end, LAG1’ will be then placed in production and will replace the original LAG1.

 

2.png

 

ServiceNow Implementation of Planned Revision

  • Navigate to the Telecom Network Inventory Workspace
  • From lists navigate to > Changes > All and select NEW
  • Two change tasks have already been added for this example. Click on the Change Tasks as indicated below.

3.png

  • Once you select the Change Tasks, there are two change tasks that have already been created.
    • CTASK0010014 Revision Demo
    • CTASK0010015 Operationalization Demo

4.png

 

  • As part of this example, an existing LAG connection has been selected.
  • Click on Network Diagram to see the visualization and composition of the LAG

5.png

 

  • From the network Diagram – This is a LAG running between ESS7450 and OLT7360 in Dallas.
  • The Lag consists of two ENET connections.
  • Planned Revision will be used to increase the capacity of the LAG connection by adding an ENET connection

6.png

 

  • An ENET connection was created for the purpose of this example seen below.
  • This new ENET connection will be added to the previous LAG Connection.

7.png

 

Planned Revision Implementation

  • Return to the newly created change requests
  • Click on Change Task: CTASK0010014 – Revision Demo

8.png

  • Under task Attribute, select the LAG that is planned to be revised from previous section.
    • 101LG/LAG/DLLSTXMR0AW/DLLSTXMROl0 (AZ/ZA)
  • Click on Submit

 9.png

 

  • The above mentioned Lag connection will now be cloned. The Cloned CI will have _V1:
    • 101LG/LAG/DLLSTXMR0AW/DLLSTXMROl0 (AZ/ZA)_V1
  • Click on the Configuration Item: 101LG/LAG/DLLST

10.png

 

  • The Cloned CI will have the exact same attributes as the orginal LAG CI
  • The difference in the clone are the status of the below:
    • Lifecycle Stage: Design
    • Lifecycle Stage Status: Build
      • In the original CI, the below will be the values
        • Lifecycle Stage: Operational
        • Lifecycle Stage Status: In Use

10.png

 

  • Click on Connection Element tab
  • The clone CI will have the same Connection Element hierarchy as seen below

11.png

 

  • Click on the Network Diagram to see that the duplicate LAG consists of the same ENET that were displayed with the original LAG earlier

12.png

 

  • Return to the cloned CI and add the new Connection Element(ENET) that was previously created
  • Click on NEW

13.png

 

  • When Creating a New Connection Element complete the following on the form:
    • Element Type: Logical Connection
    • Element: (New ENET Created)DLLSTCMR02T/DLLSTXM02T/ENET Section/100Mbps/1
    • Sequence: 1
      • Determines which order the ENETs will appear
    • Route: (changed from 1) 3
      • Determines if the routes are sequential or parallel
    • Click on SAVE

14.png

 

  • Return to the revised LAG implementation, click on Refresh
  • The new ENET has now been added.

15.png

 

  • Click on the Network Diagram Tab
  • The third ENET has been added to the new version of the LAG

16.png

  • The STATE of the Revision Task (CTASK0010014) can now be changed to Closed
    • The Revision TASK has now been completed because the CI had been successfully cloned
    • The relevant changes have also been made to the CI with the addition of an ENET Connection Element
  • Click on Close TASK

17.png

 

Operationalization Implementation of Planned Revision

  • Return to the original change request and click on the Change task (CTASK0010015)indicating Operationalization Demo Task

18.png

 

  • The Task for Operationalization will open as seen below.
    • The request type will indicate Operationalize CI
  • Click on Task Attributes

19.png

 

  • Within the task attribute form
    • CI(s) to be Operationalized
      • the CIs to be operationalized can be listed here
    • Change Request ID
      • The change request IDs can be listed as well. All the CIs affected as part of this change task will be operationalized.
    • In this example, the Change Task ID has been added CHG0030008
    • Click on Submit

20.png

 

  • Return to the Change Task CHG00100015
  • Idicates that Operationalization has been completed.
  • Also the new revision _V1 that was created has also been decommissioned since those changes have now been Operationalized (merged) into the existing LAG CI.
  • State has been changed to Close

21.png

 

  • Return to the original CI
    • Lifecycle Stage: Operational
    • Lifecycle Stage Status: In Use
    • Click on Connection Elements

22.png

 

  • In the Connection Elements, there are now 3 connection elements
  • Click on Network Diagram

23.png

 

  • A refresh may need to be applied to see the new visualization seen below
  • The new connection element (ENET) has now been added

24.png

 

  • Return to the Cloned CI
  • The below depicts that the Lifecycle Stage is End of Life and the Lifecycle Stage Status is now Retired
  • The CIs are not being automatically deleted but rather when the CMDB runs their automated archieval process, any CIs that have a  Lifecycle Stage of End of Life and the Lifecycle Stage Status of Retired is then deleted by the CMDB.
  • The duplicated CI LAG 101LG/LAG/DLLSTXMR0AW/DLLSTXMROl0 (AZ/ZA)_V1 is no longer part of Network Inventory since it was not added to the SET Inventory Attributes when it was created

25.png

 

In conclusion, as part of the planned revision support, users can make a clone of a specific CIs. They are then allowed to make changes to that clone CI. Once they Opertaionalize those changes – all the changes made to the clone CI are merged to the original CI. Finally. the Clone CI is then moved to Lifecycle Stage is End of Life and the Lifecycle Stage Status is now Retired. CMDB then deletes the cloned CI when the CMDB runs its archival process.

0 Helpfuls
  • 304 Views
Version history
Last update:
‎02-19-2024 12:52 PM
Updated by:
ServiceNow Employee
Contributors