Hi All,

Following is a proposal on the NIX Protocol - Network Information Exchange Protocol. If the Open API community concur for the need, will step into the further process of documentation and API development. Please guide and let me know your feedback.

INTRODUCTION

The following document is the proposal for standardizing the maintenance activity related email communication between network companies. Globally network companies <g class="gr_ gr_53 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="53" data-gr-id="53">do</g> partner with other network carriers for capacity augmentation and riding services to the customers. During maintenance activities that could impact the circuits of partnered companies, the communication happens in nonstandard email format. Though automation and standardization are experimented by some carriers since no standardization is in place, adopting communication means as per one's practice would be very much challenging without standardization. Hence there is a lot of manual process in place to covert the nonstandard email format communication into digital records.

While standardizing identified following key important attributes in maintenance activity that could impact partner companies' associated circuits or NEs or customers.

• Reference ID à Unique reference ID to communicate with network carrier partner for further communication regarding the maintenance activity(s)
• Network Carrier name à Sending company name who is going to perform the maintenance activity(s) that could impact the email recipient network company
• Subject à A one-line brief summary of maintenance activity(s) going to be performed
• Start Date and time along with time zones (local and GMT) à A set of start dates with associated time and zones information (In case of multiple maintenance activities planned in various windows of different dates or only one date time and zone). Time zone should be mentioned in the local time zone (EST/PST/CST) where the maintenance activity is going to be performed along with GMT +/- hours. Format MM/DD/YYYY HH24:MI<g class="gr_ gr_71 gr-alert gr_gramm gr_inline_cards gr_run_anim Style replaceWithoutSep" id="71" data-gr-id="71">:SS</g>.sss <g class="gr_ gr_57 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="57" data-gr-id="57">XST</g>/GMT-5
• End Date and time along with time zones (local and GMT) à A set of corresponding end dates, time and zone for each start date. Format MM/DD/YYYY HH24:MI<g class="gr_ gr_72 gr-alert gr_gramm gr_inline_cards gr_run_anim Style replaceWithoutSep" id="72" data-gr-id="72">:SS</g>.sss <g class="gr_ gr_58 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="58" data-gr-id="58">XST</g>/GMT-5
• Outage window Duration à If Multiple start/end dates are given either single outage window for all maintenance activities included can be provided or provide a set that corresponds to an individual pair of start/end dates. Format HH:MI<g class="gr_ gr_73 gr-alert gr_gramm gr_inline_cards gr_run_anim Style replaceWithoutSep" id="73" data-gr-id="73">:SS.sss</g>
• Impact Duration à Actual impact duration for every corresponding start/end date. Format HH:MI<g class="gr_ gr_74 gr-alert gr_gramm gr_inline_cards gr_run_anim Style replaceWithoutSep" id="74" data-gr-id="74">:SS.sss</g>
• NE Type à On what type of network element the maintenance activity is going to be performed on. Ex: - Switch/Circuit/Router
• NE Details à List of impacted NEs. If there is a relation between the date window and NEs list, then have a set of sets corresponding to each start/end dates.
• Detailed work description à A full work description of the maintenance activity. Free flow text.
• Update Flag à Is this notification an update notification of the previous email? 0 à Not an update, 1à Postpone notification, 2à Prepone notification
• Emergency à Yes or No, generally for the notifications below 24 hrs lead time this flag will be enabled
• Severity à High/Medium/Low depends on multiple factors duration, number of circuits, impacted customer base
• URL info à Any extranet URL to login and see the maintenance activity details else N/A
• Location à Where is the maintenance activity happening? Could be different locations based on the NE presence.
• Maps info à A set of Maps location URLs or lat-long coordinates or N/A
• Contact info à Contact email and phone number about the maintenance activity

Sample <g class="gr_ gr_51 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="51" data-gr-id="51">Json</g> with Maintenance Activities

 

{

  "RefID": {},

  "CarrierName": {},

  "Subject": {},

  "Actvities": {

    "Activity1": {

      "ActivityID": {},

      "StartDateTimeZone": {},

      "EndDateTimeZone": {},

      "OutageWindow": {},

      "ImpactDuration": {},

      "NEType": {},

      "NEDetails": {},

      "WorkDescription": {},

      "Location": {},

      "Severity": {}

    },

    "Activity2": {

      "ActivityID": {},

      "StartDateTimeZone": {},

      "EndDateTimeZone": {},

      "OutageWindow": {},

      "ImpactDuration": {},

      "NEType": {},

      "NEDetails": {},

      "WorkDescription": {},

      "Location": {},

      "Severity": {}

    }

  },

  "UpdateFlag": {},

  "Emergency": {},

  "URL": {},

  "MAPsInfo": {},

  "ContactEmail": {},

  "ContactPhone": {},

  "ContactAddress": {}

}

 

------------------------------
Adithya Umakanth
Verizon Communications
------------------------------

Does this differ from the trouble ticket model developed in ATIS TR 217 ( noting this is JSON Based )?

------------------------------

Dave Milham TM Forum Chief Architect, TM Forum
------------------------------

Hi Dave,

Thanks for the response,

Yes, it is different from trouble ticket model.

Trouble ticket model talks about the ticket tracking within the organization.

NIX is about maintenance activity notification across organizations. 

One Telecom/Network organization may serve N other organizations since there is no standardization in place, organizations are notifying about maintenance activities that could impact partnered networks over emails.  

I referred following two articles as per your suggestion, Please guide me if I missed reading the right articles.

https://projects.tmforum.org/wiki/pages/viewpage.action?spaceKey=PUB&title=TMF621+Trouble+Ticket+API+REST+Specification+R18.0.1
https://www.tmforum.org/resources/standard/tr217-partnership-revenue-models-v0-5-2/


Thank You
Adithya

------------------------------
Adithya Umakanth
Verizon Communications
------------------------------

Original Message:
Sent: Jan 17, 2019 05:34
From: Dave Milham
Subject: Proposal for NIX Protocol

Does this differ from the trouble ticket model developed in ATIS TR 217 ( noting this is JSON Based )?

------------------------------

Dave Milham TM Forum Chief Architect, TM Forum
------------------------------

Thanks for prompt response
Apologies got the number wrong ( typo)
Should have been T1.227 from ATIS equivalent  ITU   X790 Trouble ticketing ( not sure if ATIS has retired this standard.)
These do  address scheduled maintenance as well as trouble ticket between organisation. I was curious as to whether  NIX requirements and the schedule maintenance in this proposal were related.

------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------

Original Message:
Sent: Jan 17, 2019 05:34
From: Dave Milham
Subject: Proposal for NIX Protocol

Does this differ from the trouble ticket model developed in ATIS TR 217 ( noting this is JSON Based )?

------------------------------

Dave Milham TM Forum Chief Architect, TM Forum
------------------------------

Hi Adithya

Do you think the diversity inclusion will let the customer know that there is a diversity pathing avbl to continue the service without any disruption.

------------------------------
steve johnson
Verizon Communications
------------------------------

Hi John

Yes, we should consider if the diversity path is available that will not impact the service, worth mentioning as part of the JSON object.
Will enhance the object with your input.

Thanks a lot for your suggestion

Thank You
Adithya

------------------------------
Adithya Umakanth
Verizon Communications
------------------------------

Original Message:
Sent: Jan 17, 2019 08:25
From: steve johnson
Subject: Proposal for NIX Protocol

Hi Adithya

Do you think the diversity inclusion will let the customer know that there is a diversity pathing avbl to continue the service without any disruption.

------------------------------
steve johnson
Verizon Communications
------------------------------

Adithya, that's a good undertaking.
However I foresee difficulties figuring impact on all parties involved, as there seems to be a need to be able to correctly transcribe network service topology, across multiple parties / providers. They typically have their own databases of reference, often with incompatible format. Often having just NE name is not good, because there may be 12 shelves with 12 cards in each, and maybe 12 ports in each card. Assuming all that at risk could be blocking quite a lot. A common language to unambiguously describe infrastructure elements, services provided by network, and their relations can be tricky. From your description, ​it would be down to each responsible person to identify the actual risk based on his/her understanding of the textual description of work planned, name of the element, and probably navigation in their own data records to figure out what's at risk. E.g. the process is mostly manual - but that could just be fine with what you trying to accomplish.

------------------------------
Sergey Zak
Australia
Senior Domain Architect
------------------------------

We have  looked at the requirements for  interconnecting connectivity domains 
initial study was in ZOOM/ODA  TR275 Core Networking Resources Business Entities R18.5.0  
However we concluded in ODA GB999 User Guide for Network Slice Management R18.5.0  that for 5G ( and other connectivity services) we needed a simplified Service view of Connectivity Domains and their interconnection; so we put together the candidates entities required and the ODA Production team is now working with the SID and API teams on SID enhancement and API  Data models for connectivity Service 
this leverages thinking in API and SID program and prior ZOOM /ODA work in  TR255 Resource Function Activation and Configuration Suite R17.5.0  especially Parts A and B . This proposed a service view of the resource topologies which means operators don't have to reveal all the low level resource topology as part of the Connectivity Service which means the service topology is much simply and does not change when underlying resources change as happens with virtualised solution.  It also addresses network security needs

------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------

Original Message:
Sent: Jan 20, 2019 17:36
From: Sergey Zak
Subject: Proposal for NIX Protocol

Adithya, that's a good undertaking.
However I foresee difficulties figuring impact on all parties involved, as there seems to be a need to be able to correctly transcribe network service topology, across multiple parties / providers. They typically have their own databases of reference, often with incompatible format. Often having just NE name is not good, because there may be 12 shelves with 12 cards in each, and maybe 12 ports in each card. Assuming all that at risk could be blocking quite a lot. A common language to unambiguously describe infrastructure elements, services provided by network, and their relations can be tricky. From your description, ​it would be down to each responsible person to identify the actual risk based on his/her understanding of the textual description of work planned, name of the element, and probably navigation in their own data records to figure out what's at risk. E.g. the process is mostly manual - but that could just be fine with what you trying to accomplish.

------------------------------
Sergey Zak
Australia
Senior Domain Architect
------------------------------

WRT  Network Carrier name

Carrier codes are issued and maintained by the ITU 
See https://www.itu.int/oth/T0201

Data network Identifier DNIC in ITU Operational bulletins see https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-OB.714-2000-PDF-E.pdf

Int'l Leased circuit identifier structure is ITU  M.1400  series  see
https://www.itu.int/rec/T-REC-M.1400/en

Which is why I asked the question about X.790 which includes scheduled maintenance and was originally developed for int'l leased circuits.

------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------

Hi All,

Thanks a lot for the inputs,

Here are my thoughts on NIX Proposal

1) I am not proposing standardization in Circuit naming convention.
2) Verizon partners with 250 other network organizations globally (Both in the domestic US and internationally)
3) We receive maintenance notification emails in non-standard format by the carrier. (Attached 5 sample emails from different carriers globally) 
4) NIX is a proposal to standardize the email format only, create Open API to generate and read such standardized emails.
5) Without standardization, these network/telecom organizations are relying on manual/rules/tools to process these emails and feed into internal systems.

Please let me know how to proceed.

------------------------------
Adithya Umakanth
Verizon Communications
------------------------------

Original Message:
Sent: Jan 21, 2019 03:10
From: Dave Milham
Subject: Proposal for NIX Protocol

WRT  Network Carrier name

Carrier codes are issued and maintained by the ITU
See https://www.itu.int/oth/T0201

Data network Identifier DNIC in ITU Operational bulletins see https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-OB.714-2000-PDF-E.pdf

Int'l Leased circuit identifier structure is ITU  M.1400  series  see
https://www.itu.int/rec/T-REC-M.1400/en

Which is why I asked the question about X.790 which includes scheduled maintenance and was originally developed for int'l leased circuits.

------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------