Subject: Re: [Lime] [L3sm] Welcome to the working group

From: Qin Wu <[email-masked]>
Date: Sat, 25 Apr 2015 01:42:40 +0000

Maximum:
It seems to me you are talking about OAM requirement, I believe SLA parameters you are referred to is more related to OAM.
SLA monitoring and troubleshoot can be well addressed by a separate model, LIME base YANG model.
LIME working group look at OAM aspect and is working on LIME base model for generic layer-independent and 
technology-independent configuration, reporting and presentation for OAM mechanisms.
http://tools.ietf.org/wg/lime/charters

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Maxim Klyus
发送时间: 2015年4月24日 20:04
收件人: [email-masked]; [email-masked]; [email-masked]
主题: Re: [L3sm] Welcome to the working group

Stephane and all,

I agree we can try to align it with other models.
I also agree status can have 2 leaves - cfg (administrative?) and operational with different states.

I don't think I see some other possible operational states now.
But I want to clarify one thing about active-error state, because I have many questions regarding this state.

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 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?

It could be just sla-level-parameter - some integer value. Integer value could be mapped to some decision-policy, however decision-policy is definitely out of scope l3vpn mode.

Best Regards,
Maxim Klyus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 24, 2015 2:22 PM
To: Maxim Klyus; [email-masked]; [email-masked]
Subject: RE: [L3sm] Welcome to the working group

Hi,

Regarding ops state, there is a discussion on going for device config related model on how it should be handled.
There is the idea of having the same tree or same tree structure for cfg & ops state, so it would be possible to compare what has been configured and what is really used by the device.
In term of service model, I'm wondering if this is still applicable or not ? or we could just use some status leaves as you propose.
Do you see other kind of operational states rather than the status ?

Thx,

Stephane

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Monday, April 06, 2015 21:02
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] Welcome to the working group

Hello, L3SM and Adrian.

I'm not sure if below information should be forwarded to draft-l3vpn-service-yang mail-list.

But here is my objection for contribution and discussion in L3SM WG from NetCracker side.

imho  STATUS parameter - one of the forgotten things in current l3vpn service yang model and it is not related to equipment configuration directly.
As far as we are talking about services, Service Status need to be defined for L3VPN service itself, L3VPN Service Components and L3VPN Service Parts(?).

Status parameter is very important thing for service management and service integrity / SLA monitoring and troubleshooting.

L3VPN Service can have following basic statuses:

1) Planed(?) - configuration is ready to use but not applied to the equipment
2) Active - all service components have Active operational status without errors
3) Active-Error - Error/Disabled state for some of the service components
4) Suspended - service administratively stopped
5) Active-Suspended - part of the service administratively disabled
6) Disconnected(?) - service configuration removed from the equipment

Service Component can have following basic statuses:

1) Active - all related process and components have Active operational status without errors
2) Active-Error - internal errors (interface overload/errors, protocol errors, routing tables overload...etc) or related components errors
2) Disabled - administratively disabled
3) Error-Disabled - Component Error (error-disabled interface, error-disabled protocol process, error-disabled related component...etc)

Service Component can have reference to other Service Component.

In some cases L3VPN Service can be decomposed to Service parts. Like an example can be HUB&Spoke topology.
Each Spoke side or HUB side can be defined like Service Part.
Service part(?) - set of the components, can be additional abstraction for management and monitoring convenience purpose.

Service Part(?) can have following basic statuses:

1) Planed(?) - configuration is ready to use but not applied to the equipment
1) Active - all service components have Active operational status without errors
2) Active-Error - Error/Disabled state for some of the mandatory service components
2) Suspended - service administratively stopped
3) Disconnected(?) - service configuration removed from the equipment

Overall structure example:

Service
 +--Service Status
 +--Service Part                                     Reference
       +-- Service Part Status                       String
       +-- Service Component                         Reference
              +-- Service Component Status           String
              +-- Service Component                  Reference
                    +-- Service Component Status     String

L3VPN Service structure example:

module: ietf-l3vpn-svc
      +--rw l3vpn-svc
         +--rw  l3vpn-status                                                     String
         +--rw sites* [site-id]
              +--rw site-status                                                  String
              +--rw attachment
              |  +--rw apply-template?                                           leafref
                  +--rw bearer
                  |    +--rw bearer status                                       String
                  +--rw connection
                         +--rw connection-status
                               +--rw routing-protocols* [type]
                                     +--rw ospf
                                     |     +--rw ospf-protocol-status            String
                                     +---rw bgp
                                             +--rw bgp-protocol-status           String

If anybody has any comments or objections, I'm ready to discuss.

Best Regards,
Maxim Klyus

________________________________________
From: L3sm [[email-masked]] on behalf of Adrian Farrel [[email-masked]]
Sent: Wednesday, March 25, 2015 3:26 PM
To: [email-masked]
Subject: [L3sm] Welcome to the working group

Hi L3SM,

Setting up the working group has moved pretty fast, and Qin and I have only just found out we are your chairs.

Can we ask for a little time to get our act together and work out how the WG should progress towards its milestone.

In the meantime, it would be really helpful if you could send your comments on draft-l3vpn-service-yang to the mailing list.

If you have your own draft in this area, the best approach would be to look at draft-l3vpn-service-yang and see what you would change or add to that draft, then send your comments to the mailing list. Don't forget that we are strictly limited by what is in our charter.

Thanks,
Adrian

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

________________________________
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.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

________________________________
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.

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sun, 26 Apr 2015 17:10:40 +0000

Hi Qin

I tend to disagree with your comment. The same OAM report value (e.g., certain delay measurement) can represent an SLA violation for a given L3VPN (according to the discussion below) but not for another one.

Best regards

Luis

> -----Mensaje original-----
> De: Lime [mailto:[email-masked]] En nombre de Qin Wu
> Enviado el: sábado, 25 de abril de 2015 3:43
> Para: Maxim Klyus; [email-masked]; [email-masked]; [email-masked]
> Asunto: Re: [Lime] [L3sm] Welcome to the working group
>
> Maximum:
> It seems to me you are talking about OAM requirement, I believe SLA
> parameters you are referred to is more related to OAM.
> LIME working group look at OAM aspect and is working on LIME base model
> for generic layer-independent and technology-independent configuration,
> reporting and presentation for OAM mechanisms.
> 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 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?
>
> It could be just sla-level-parameter - some integer value. Integer value could
> be mapped to some decision-policy, however decision-policy is definitely out
> of scope l3vpn mode.
>
> Best Regards,
> Maxim Klyus
>
>
> There is the idea of having the same tree or same tree structure for cfg & ops
> state, so it would be possible to compare what has been configured and
> what is really used by the device.
> In term of service model, I'm wondering if this is still applicable or not ? or we
> could just use some status leaves as you propose.
> imho  STATUS parameter - one of the forgotten things in current l3vpn
> service yang model and it is not related to equipment configuration directly.
> As far as we are talking about services, Service Status need to be defined for
> L3VPN service itself, L3VPN Service Components and L3VPN Service Parts(?).
>
> Status parameter is very important thing for service management and service
> integrity / SLA monitoring and troubleshooting.
>
> 2) Active-Error - internal errors (interface overload/errors, protocol errors,
> routing tables overload...etc) or related components errors
> 3) Error-Disabled - Component Error (error-disabled interface, error-disabled
> protocol process, error-disabled related component...etc)
>
>
> Service part(?) - set of the components, can be additional abstraction for
> management and monitoring convenience purpose.
>
> In the meantime, it would be really helpful if you could send your comments
> on draft-l3vpn-service-yang to the mailing list.
>
> If you have your own draft in this area, the best approach would be to look at
> draft-l3vpn-service-yang and see what you would change or add to that
> draft, then send your comments to the mailing list. Don't forget that we are
> strictly limited by what is in our charter.
>
> Thanks,
> Adrian
>
> 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.
>
> __________________________________________________________
> __________________________________________________________
> _____
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> 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.
>
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Qin Wu <[email-masked]>
Date: Mon, 27 Apr 2015 03:30:38 +0000

Hi, Luis:
Thanks for sharing your opinion. Can you tell what kind of SLA parameters you really want to look into?
I believe QoS requirement and Bandwidth requirement have already been described in the draft-l3vpn-service-yang at the site level.
Yes, the same reported OAM value can represent SLA violation for one customer but not for the other. I assume you are talking about customer level SLA.

But Delay is only measured after the network is up and network configuration is applied.
delay between two sites(e.g., round trip delay from PE to PE) may vary with the service type (e.g.,real time service, data service, voice service) or distance between two sites.
Delay between any two sites belonging to the same VPN can be different if two sites are allowed to interconnect.
If we add delay as global parameter in the service model, we need to add delay for each pair of sites belong to one VPN which seems to me complicated.

On the other hand, OAM model developed by the LIME WG provides a component to measure delay and other network performance metrics and can well address troubleshooting
requirements. Performance Management model will be available soon in the LIME WG.

-Qin
-----邮件原件-----
发件人: LUIS MIGUEL CONTRERAS MURILLO [mailto:[email-masked]] 
发送时间: 2015年4月27日 1:11
收件人: Qin Wu; Maxim Klyus; [email-masked]; [email-masked]; [email-masked]
主题: RE: [L3sm] Welcome to the working group

Hi Qin

I tend to disagree with your comment. The same OAM report value (e.g., certain delay measurement) can 
represent an SLA violation for a given L3VPN (according to the discussion below) but not for another one.

Best regards

Luis

> De: Lime [mailto:[email-masked]] En nombre de Qin Wu Enviado 
> el: sábado, 25 de abril de 2015 3:43
> Maxim:
> LIME working group look at OAM aspect and is working on LIME base 
> model for generic layer-independent and technology-independent 
> configuration, reporting and presentation for OAM mechanisms.
> But I want to clarify one thing about active-error state, because I 
> have many questions regarding this state.
>
> 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.
> (error numbers, etc.. ) and rules to be able to say if VPN service is 
> unavailable = error-disabled.
>
> At this point I have open question 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?
>
> It could be just sla-level-parameter - some integer value. Integer 
> value could be mapped to some decision-policy, however decision-policy 
> is definitely out of scope l3vpn mode.
>
> Best Regards,
> Maxim Klyus
>
>
> Regarding ops state, there is a discussion on going for device config 
> related model on how it should be handled.
> There is the idea of having the same tree or same tree structure for 
> cfg & ops state, so it would be possible to compare what has been 
> configured and what is really used by the device.
> In term of service model, I'm wondering if this is still applicable or 
> not ? or we could just use some status leaves as you propose.
> As far as we are talking about services, Service Status need to be 
> defined for L3VPN service itself, L3VPN Service Components and L3VPN Service Parts(?).
>
> Status parameter is very important thing for service management and 
> service integrity / SLA monitoring and troubleshooting.
>
> 2) Active-Error - internal errors (interface overload/errors, protocol 
> errors, routing tables overload...etc) or related components errors
> 3) Error-Disabled - Component Error (error-disabled interface, 
> error-disabled protocol process, error-disabled related 
> component...etc)
>
>
> Service part(?) - set of the components, can be additional abstraction 
> for management and monitoring convenience purpose.
>
> Can we ask for a little time to get our act together and work out how 
> the WG should progress towards its milestone.
>
> In the meantime, it would be really helpful if you could send your 
> comments on draft-l3vpn-service-yang to the mailing list.
>
> If you have your own draft in this area, the best approach would be to 
> look at draft-l3vpn-service-yang and see what you would change or add 
> to that draft, then send your comments to the mailing list. Don't 
> forget that we are strictly limited by what is in our charter.
>
> Thanks,
> Adrian
>
> 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.
>
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> 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: Gregory Mirsky <[email-masked]>
Date: Mon, 27 Apr 2015 03:58:28 +0000

Hi Luis,
I agree, measured performance metric may or may be out of SLA profile. I believe that if we to define Service Degradation defect, then, as suggested by its name, it can only be per service which is characterized , quantified through SLA. And I think that single out-of-SLA measured metric yet not constitutes the SD defect and only N consecutive out-of-SLA measurements, where N MAY be defined for every SLA individually, do. Similarly, out-of SD defect exit condition would be M consecutive in-SLA measurements. 
Would appreciate comments and questions.

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Sunday, April 26, 2015 10:11 AM
To: Qin Wu; Maxim Klyus; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lime] [L3sm] Welcome to the working group

Hi Qin

Best regards

Luis

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________
Lime mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lime