Subject: [Supa] yang model common set

From: Maxim Klyus <[email-masked]>
Date: Thu, 9 Apr 2015 13:37:16 +0000

Hi, L3SM, SUPA.

Other very important missed things I see in drafts - TRANSACTION and TRANSACTION STATUS.
Unfortunately YANG doesn't support transactions by itself now, so 2 above parameters should be included in the models.

If we have let say 2 modification configurations for the same service but with different parameters, it goes one by one...
And we don't have any transaction information after that, we even don't know if first transaction was started/finished, or may be some config-messages lost...
So it could be very big problem in service management and orchestration.

So my suggestion to add following in l3vpn service draft and draft-zaalouk:

leaf transaction {

leaf id {
   type uint32;
   description
   "Transaction ID number"

   }

leaf transaction-type {

  type enumeration {

             enum Create {

               value 1;

               description

                 "Transaction queued"

            }

             enum Delete {

               value 2;

               description

                 "Transaction in progress"

            }

             enum Modify {

               value 3;

               description

                 "Transaction finished successfully"

            }

             enum Verify {

               value 4;

               description

                 "Transaction finished successfully"

            }

leaf transaction-status {

  type enumeration {

             enum Queued {

               value 1;

               description

                 "Transaction queued"

            }

             enum In-Progress {

               value 2;

               description

                 "Transaction in progress"

            }

             enum Finished - OK {

               value 3;

               description

                 "Transaction finished successfully"

            }

             enum Finished - Erros {

               value 4;

               description

                 "Transaction finished with errors"

            }

             enum Canceled {

               value 5;

               description

                 "Transaction canceled"

            }

             enum Timeout {

               value 6

               description

                 "Transaction canceled by timeout"

            }

       }
   }
}

Any comments?

P.S. My Yang model can probably have an errors so please correct me in case.

Best Regards,
Maxim Klyus

________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 15:52:52 +0200

Hi,

you may want to read RFC 6241. Transactions are seen as a protocol
concept, not a data modeling concept. RFC 6241 also explains how to
run transactions across multiple NETCONF servers.

/js

> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Maxim Klyus <[email-masked]>
Date: Thu, 9 Apr 2015 14:04:42 +0000

Juergen,
Thank you.

Sorry everybody for this inconvenience.
Question closed.

Best Regards,
Maxim Klyus

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, April 09, 2015 4:53 PM
To: Maxim Klyus
Cc: [email-masked]; [email-masked]
Subject: Re: [Supa] yang model common set

Hi,

you may want to read RFC 6241. Transactions are seen as a protocol concept, not a data modeling concept. RFC 6241 also explains how to run transactions across multiple NETCONF servers.

/js