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

From: Maxim Klyus <[email-masked]>
Date: Mon, 6 Apr 2015 19:01:51 +0000

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.

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 7 Apr 2015 17:07:34 +0200

Maxim, Adrian, all,

Operational status is probably an excellent idea to have in the model. We should make sure this status is marked config false, though, as it changes spontaneously and not by operator configuration. While the operator cannot configure the operational status, he should be able to s set the admin status. Se we should probably add that as well.

So I’d suggest something like this pseudo-yang:

leaf status {
  config false;
  type enumeration {
    enum planned;
    enum active;
    enum active-error;
    enum suspended;
    enum active-suspended;
    enum disconnnected;
  }
}
leaf admin-status {
  type enumeration {
    enum planned;
    enum active;
    enum inactive;
  }
}

These leafs will occur in several places, I believe, so we should use typedefs. The exact names and number of states could also be debated.

Best Regards,
/Jan Lindblad, YANGdr

> On 6 apr 2015, at 21:01, Maxim Klyus <[email-masked]> wrote:
> 
> Hello, L3SM and Adrian.
>

---

From: <[email-masked]>
Date: Tue, 7 Apr 2015 15:56:54 +0000

+1

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Jan Lindblad
Sent: Tuesday, April 07, 2015 17:08
To: Maxim Klyus
Cc: [email-masked]; [email-masked]
Subject: Re: [L3sm] Welcome to the working group

Maxim, Adrian, all,

leaf status {
  config false;
  type enumeration {
    enum planned;
    enum active;
    enum active-error;
    enum suspended;
    enum active-suspended;
    enum disconnnected;
  }
}
leaf admin-status {
  type enumeration {
    enum planned;
    enum active;
    enum inactive;
  }
}

Best Regards,
/Jan Lindblad, YANGdr

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

_________________________________________________________________________________________________________________________

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.

---

From: Maxim Klyus <[email-masked]>
Date: Wed, 8 Apr 2015 18:02:11 +0000

Jan and all,

I think we can reference to following RFC:  https://tools.ietf.org/html/rfc4176  section " 3.  Provider Network Manager”

We see VPN Service can have different Statuses.

Jan, I agree your pseudo yang model could be initial point for discussion.

Also the problem I see now - not all L3VPN related objects/components have Status parameter.

As Jan pointed it could be an Admin Status, but Admin Status don’t reflects object / component “health state” – Normal/Errors/Overload..ect

Each VPN related object/component has some other specific parameters related to VPN service status.

Like an example until BGP state != established  we can say it will be Error Status for particular VPN Services.

This specific object states can be converted into a limited Status states for related VPN Services.

Because VPN Service need to know only if it still can operate with current related object status.

And we can call this object/component parameter – unified service status or we can call it unified operational status.

I think this conversion job could be done by NEs or with intermediate management point like SDN Controller.

On SDN Controller we can define the correlation rules for Status conversion.

And I think operational status should present directly on each objects/component related to VPN Service.

So I’d like to suggest add Operational Status for VPN components also, the number of states could be debated.

leaf oper-status {

  type enumeration {

             enum Active {

               value 1;

               description

                 "Component is Active”

            }

             enum Active-Error {

               value 2;

               description

                 "Component is Active”

            }

             enum Error-Disabled {

               value 3;

               description

                 "Component is Active”

            }

      }

}

And I have an open question if we should to discuss this topic with NETMOD WG?

As far as I know some similar things was defined in YANG Interface Management https://tools.ietf.org/html/rfc7223

“leaf oper-status {

           type enumeration {

             enum up {

               value 1;

               description

                 "Ready to pass packets.";” …etc

}

Any comments?

Best Regards,

Maxim Klyus

-----Original Message-----
From: Jan Lindblad [mailto:[email-masked]]
Sent: Tuesday, April 07, 2015 6:08 PM
To: Maxim Klyus
Cc: [email-masked]; [email-masked]
Subject: Re: [L3sm] Welcome to the working group

Maxim, Adrian, all,

leaf status {

  config false;

  type enumeration {

    enum planned;

    enum active;

    enum active-error;

    enum suspended;

    enum active-suspended;

    enum disconnnected;

  }

}

leaf admin-status {

  type enumeration {

    enum planned;

    enum active;

    enum inactive;

  }

}

Best Regards,

/Jan Lindblad, YANGdr

> On 6 apr 2015, at 21:01, Maxim Klyus <[email-masked]<mailto:[email-masked]>> wrote:

> 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

> 1) Active - all related process and components have Active operational

> status without errors

> 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

> From: L3sm [[email-masked]] on behalf of Adrian Farrel

> [[email-masked]]

> To: [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 24 Apr 2015 11:22:09 +0000

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.

Service
 +--Service Status

module: ietf-l3vpn-svc
      +--rw l3vpn-svc

Best Regards,
Maxim Klyus

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

---

From: Maxim Klyus <[email-masked]>
Date: Fri, 24 Apr 2015 12:04:10 +0000

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,

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.

Service
 +--Service Status

module: ietf-l3vpn-svc
      +--rw l3vpn-svc

Best Regards,
Maxim Klyus

Hi L3SM,

Thanks,
Adrian

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.

---

From: "Tomotaki, Luis M" <[email-masked]>
Date: Fri, 24 Apr 2015 11:27:37 -0400

Maxim and team, 
Partially based on your 3 site VPN example, I believe that managing operational state for an entire VPN service would be difficult to implement and of little value since the details of the failure would need to be addressed at the component level.  I think operational state applies more to components instead of the overall VPN service.  Similarly, I also believe that SLA parameters/SLA rules fall outside the scope of the draft even though I think it is an item that definitely needs to be addressed.  

Personally, I would think that Provisioning transaction success/failure status for configuring the VPN service would be useful, but as you stated earlier, it should be handled by a protocol such as NETCONF and falls outside the scope of this draft.  

Regards,
Luis Tomotaki

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, April 24, 2015 7:04 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [L3sm] Welcome to the working group

Stephane and all,

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,

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.

Service
 +--Service Status

module: ietf-l3vpn-svc
      +--rw l3vpn-svc

Best Regards,
Maxim Klyus

Hi L3SM,

Thanks,
Adrian

---

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,

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,

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.

Service
 +--Service Status

module: ietf-l3vpn-svc
      +--rw l3vpn-svc

Best Regards,
Maxim Klyus

Hi L3SM,

Thanks,
Adrian

---

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

Maxim:

Speaking as individual (without co-chair’s hat).

How does the customer know service status before service model is fed into service orchestrator?

Is there any difference between service status and cfg&ops state?

I can understand we need a process to map service model onto network element YANG model?

Do we need another process to get cfg&state from network element model after configurations are applied and the network is running and **map back** to service model?

Is this your proposal to establish mapping between cfg&ops state in the network element model and service status in the service model?

What's the benefit to have such mapping if my understanding is correct and this is your proposal?

-Qin

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

Hi,

Thx,

Stephane

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hello, L3SM and Adrian.

Service

+--Service Status

module: ietf-l3vpn-svc

      +--rw l3vpn-svc

         +--rw sites* [site-id]

              +--rw site-status                                                  String

              +--rw attachment

                  +--rw bearer

                  +--rw connection

                         +--rw connection-status

                                     +--rw ospf

                                     +---rw bgp

Best Regards,

Maxim Klyus

Hi L3SM,

Thanks,

Adrian

L3sm mailing list

L3sm mailing list

Thank you.

L3sm mailing list

---

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.
>
> 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
> 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.
>
> Service part(?) - set of the components, can be additional abstraction 
> for management and monitoring convenience purpose.
>
> 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

---

From: Maxim Klyus <[email-masked]>
Date: Mon, 27 Apr 2015 12:32:02 +0000

Qin and all,

>>>“How does the customer know service status before service model is fed into service orchestrator? “

Service customer portal like an example: Customer making order and he can see service status changed to Planned, deployment in progress, etc…

>>>“Is there any difference between service status and cfg&ops state? “

After all discussions my current proposal to divide Status in 2 leaves:

1)    Administrative Status – Life Cycle Management and Configuration (this states more related to service operator but can be used by subscriber also)

States:

-          Planned – service planed, service configuration prepared, resources temporary allocated and reserved (Operational States = Inactive)

-          Enabled – service enabled, service configuration applied to service components (Operational States = Active / Error)

-          Disabled – service disabled administratively, key service components disabled but resources still allocated to service, service configuration changed (Operational States = Inactive/Error-Disabled)

-          Partly – Suspended – service partly disabled administratively, some of the key service components disabled but will be enabled later, service configuration changed (Operational States = Active / Error)

If we reviewing VPN service from configuration side, but not like service object side we can stay only Disabled/Suspended, but we need add to the model parameter: Service Configuration Revision. So we able to track when last changes occurred for service and what actually were changed.

Because right now I can see “rw-id” in the model and I guess it is Service Id but not service configuration revision id.

Why it could be important to know if service Suspended or Partly – Suspended? For operator it could be important from the resource allocation side because service changed but it may be still needs temporary disabled resources (except service modification case when resources disconnected in total) and subscriber just would like to know such kind of information obviously.

-          Disconnected - service  disconnected, configuration removed from the service components and saved for history and resources are free now (Operational States = Inactive)

2)    Operational Status – Service operational states (this states related to both – customer and service operator)

States:

-          Active – service is active (Administrative Status State = Partly-Suspended / Enabled)

-          Error – service still active but have some errors (Administrative Status State = Partly-Suspended / Enabled)

-          Error-Disabled – service have to many errors and seems to be disabled (Administrative Status State = Disabled/Partly-Suspended / Enabled)

-          Inactive – service is inactive because (Administrative Status State = Planned/Disabled/Disconnected)

Previously I proposed to add Status for VPN service components to be able to do service integrity check, but after our very useful discussion I’m not sure it will be necessary, because we can see service integrity decision can be unique per service basis and very complicated, each service components can have many very specific parameters for monitoring.
Also as you said independent OAM model already exists, but right now it is more related to Delay parameter only and we should have several OAM instances per one service.
However service integrity decision can be much more complicated like specific decision policy which includes sets of different OAM instances related to different components and some set of conditions related to SLA.

Considering all the above, my proposal instead of defining Status for VPN Components just provide only one additional parameter in model – SLA-Policy parameter it will be reference to some complicated SLA decision policy which out of scope of this draft. But I just think it will be useful to have such possibility in model, even considering ietf don’t have any defined sla-decision-policy, any service operator can use such parameter for internal (custom) SLA decision process implementation.

Max Klyus

From: Qin Wu [mailto:[email-masked]]
Sent: Saturday, April 25, 2015 4:44 AM
To: [email-masked]; Maxim Klyus; [email-masked]; [email-masked]
Subject: RE: [L3sm] Welcome to the working group

Maxim:

-Qin

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

Hi,

Thx,

Stephane

-----Original Message-----

Hello, L3SM and Adrian.

Service

+--Service Status

module: ietf-l3vpn-svc

      +--rw l3vpn-svc

         +--rw sites* [site-id]

              +--rw site-status                                                  String

              +--rw attachment

                  +--rw bearer

                  +--rw connection

                         +--rw connection-status

                                     +--rw ospf

                                     +---rw bgp

Best Regards,

Maxim Klyus

Hi L3SM,

Thanks,

Adrian

L3sm mailing list

L3sm mailing list

Thank you.

L3sm mailing list

---

From: Maxim Klyus <[email-masked]>
Date: Mon, 27 Apr 2015 12:41:26 +0000

My apologies,

Small correction:

-          Error-Disabled – service have to many errors and seems to be disabled (Administrative Status State = Disabled)

Best Regards,
Maxim Klyus

From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Monday, April 27, 2015 3:32 PM
To: Qin Wu; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [L3sm] Welcome to the working group

Qin and all,

States:

States:

Max Klyus

From: Qin Wu [mailto:[email-masked]]
Sent: Saturday, April 25, 2015 4:44 AM
To: [email-masked]<mailto:[email-masked]>; Maxim Klyus; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] Welcome to the working group

Maxim:

-Qin

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

Hi,

Thx,

Stephane

-----Original Message-----

Hello, L3SM and Adrian.

Service

+--Service Status

module: ietf-l3vpn-svc

      +--rw l3vpn-svc

         +--rw sites* [site-id]

              +--rw site-status                                                  String

              +--rw attachment

                  +--rw bearer

                  +--rw connection

                         +--rw connection-status

                                     +--rw ospf

                                     +---rw bgp

Best Regards,

Maxim Klyus

Hi L3SM,

Thanks,

Adrian

L3sm mailing list

L3sm mailing list

Thank you.

L3sm mailing list