Dear OPSAWG,

This new draft  https://datatracker.ietf.org/doc/draft-quilbeuf-opsawg- 
configuration-tracing/ aims at tracing a configuration change in a device back 
to the service request made to an orchestrator that caused the configuration 
change in the device.

I will present this draft during the OPSAWG session at IETF 115.

In the meantime, any feedback is welcome.

Best,
Jean



> -----Original Message-----
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Thursday 20 October 2022 09:59
> To: Diego R. Lopez <diego.r.lo...@telefonica.com>; Benoit Claise
> <benoit.cla...@huawei.com>; Diego Lopez <diego.r.lo...@telefonica.com>;
> Jean Quilbeuf <jean.quilb...@huawei.com>; Qiong Sun
> <sunqi...@chinatelecom.cn>; Sun Qiong <sunqi...@chinatelecom.cn>;
> Thomas Graf <thomas.g...@swisscom.com>
> Subject: New Version Notification for draft-quilbeuf-opsawg-configuration-
> tracing-00.txt
> 
> 
> A new version of I-D, draft-quilbeuf-opsawg-configuration-tracing-00.txt
> has been successfully submitted by Jean Quilbeuf and posted to the IETF
> repository.
> 
> Name:         draft-quilbeuf-opsawg-configuration-tracing
> Revision:     00
> Title:                External Transaction ID for Configuration Tracing
> Document date:        2022-10-20
> Group:                Individual Submission
> Pages:                15
> URL:            https://www.ietf.org/archive/id/draft-quilbeuf-opsawg-
> configuration-tracing-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-quilbeuf-opsawg-
> configuration-tracing/
> Html:           https://www.ietf.org/archive/id/draft-quilbeuf-opsawg-
> configuration-tracing-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-quilbeuf-opsawg-
> configuration-tracing
> 
> 
> Abstract:
>    Network equipments are often configured by a variety of network
>    management systems (NMS), protocols, and people.  If a network issue
>    arises because of a wrong configuration modification, it's important
>    to quickly identify the specific service request and obtain the
>    reason for pushing that modification.  Another potential network
>    issue can stem from concurrent NMS's with overlapping intent, each
>    having their own tasks to perform: in such a case, it's important to
>    map the respective modifications to its originating NMS.  This
>    document specifies a mechanism to automatically map the configuration
>    modifications to their source, up to a specific NMS service request,
>    in the context of NETCONF.  Such a mechanism is required for
>    autonomous networks, to trace the reason of a particular
>    configuration change that lead to an anomaly detection or a broken
>    SLA.  This mechanism facilitates the troubleshooting, the post mortem
>    analysis, and in the end the closed loop automation required for
>    self-healing networks.  The specifications contain a new YANG module
>    mapping a local configuration change to the corresponding northbound
>    transaction, up to the controller or even the orchestrator.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to