Subject: [Supa] zaalouk draft changes proposal

From: Maxim Klyus <[email-masked]>
Date: Tue, 21 Apr 2015 10:11:47 +0000

Hello SUPA,

2 files:

1)    Zaalouk-changes - only the last changes proposed for zaalouk  draft highlighted below (*changes remark).

2)    full document draft including changes and comments

Any comments appreciated.

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, 23 Apr 2015 11:00:18 +0200

> 2)    full document draft including changes and comments

I suggest to _not_ define access-interface-oper-status. Instead
explain how oper-status in the ietf-interfaces.yang module works for
VPN interfaces controlled by the VPN service model.

I do not understand 'Planned' as an administrative state for
instance-admin-state. I can have many reasons for disabling an
instance - why is it useful to pick one out of the many and make it a
special state?

I do not know what 'Active-Error' means. Is the instance working or
not? What does 'partly suspended' mean and why do we need
Active-Suspended? I also do not understand why Planned is "Active"
according to the description.

In general, we prefer to write enum labels in lowercase in YANG
modules.

I do not know where all the restrictions for physical-node or password
are coming from. I am also not sure what it means to change the status
of a physical node. If this is really supposed to change the status of
the physical node, then I would say this model is the wrong place to
do so.

And finally, please use a YANG compiler to make sure the module is
correct. A compiler would have caught things like two enums with the
same numeric value. And finally, if you want to reuse the same admin
oper state values in multiple places, consider defining a typedef of
grouping instead of repeating things N times.

/js

-- 
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, 23 Apr 2015 15:17:34 +0000

Juergen and all,

1)    I agree access-interface-oper-status should be explained more detailed.

2) " I do not understand 'Planned' as an administrative state" - my mistake, I have some doubts before and now if Planned/Disconnected states should be in operational status or it should be in administrative status.
      Because may be it is not correct to say about some service operations when service just Planned or Disconnected. But I agree it should be removed from one of the statuses.
      If everybody agreed both of it should be in operational status. It's ok.

3) "Active-Error" let's take an example: L3VPN connecting 3 sides. Side 1 and Side 2 works perfectly but side 3 periodically have some service interruptions because for some reasons to many errors or dropped packets on access interface.
    So we can say technically VPN instance still can work, but service can be partly unavailable for one side. Should we assume VPN service unavailable in total?
    It could be important for SLA monitoring and troubleshooting. If we don't have some strict SLA agreement with subscriber we can assume VPN service still active, but we should fix issues anyway.
    If we have some strict SLA agreement then we should have some criteria (error numbers, etc.. ) and rules to be able to say if VPN service is unavailable = error-disabled.

    At this point I have open question to SUPA should we add some SLA parameters / SLA rules to the VPN model or it out of scope? Should that question be addressed to some other WG?

    "Active -Suspended" the same example: L3VPN connecting 3 sides. For some technical/business reasons we need to stop service on Side 1, however Side 2 and 3 still can be online and we also sure Side1 should be active later.

   "why Planned is "Active" according to the description" - my mistake

4) " enum labels in lowercase" - accepted.

5) " status of a physical node" - I agree status here should be read-only for monitoring purpose

6) "please use a YANG compiler" - accepted.

Best Regards,
Maxim Klyus

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, April 23, 2015 12:00 PM
To: Maxim Klyus
Cc: [email-masked]
Subject: Re: [Supa] zaalouk draft changes proposal

> 2)    full document draft including changes and comments

I suggest to _not_ define access-interface-oper-status. Instead explain how oper-status in the ietf-interfaces.yang module works for VPN interfaces controlled by the VPN service model.

I do not understand 'Planned' as an administrative state for instance-admin-state. I can have many reasons for disabling an instance - why is it useful to pick one out of the many and make it a special state?

I do not know what 'Active-Error' means. Is the instance working or not? What does 'partly suspended' mean and why do we need Active-Suspended? I also do not understand why Planned is "Active"
according to the description.

In general, we prefer to write enum labels in lowercase in YANG modules.

I do not know where all the restrictions for physical-node or password are coming from. I am also not sure what it means to change the status of a physical node. If this is really supposed to change the status of the physical node, then I would say this model is the wrong place to do so.

And finally, please use a YANG compiler to make sure the module is correct. A compiler would have caught things like two enums with the same numeric value. And finally, if you want to reuse the same admin oper state values in multiple places, consider defining a typedef of grouping instead of repeating things N times.

/js

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