Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Apr 2016 12:43:38 +0200

Dear all,

Feedback from Kristian Larsson, forwarded with permission.

Regards, Benoit

===============================================================

Benoit,

in my head this model is used not only as an internal representation but
also to allow a customer to manage a L3VPN that we (or someone else)
provides. I wonder how we as the provider can limit the amount of
features that we support. The model includes RIP, OSPF and BGP as PE-CE
protocols. There are multicast portions in there and so forth. If we
choose to only provide BGP as routing protocol, how can we signal this
to the customer? Should we declare deviations? I suppose we can always
return an error when the customer sends this to us, but that's not very
elegant to do in a model driven world. Introducing if-feature into the
model would perhaps be one way, or that the model be carved up into many
smaller models that augments base model, for example:
    - l3vpn-base
    - l3vpn-bgp
    - l3vpn-rip
    - l3vpn-ospf

If we only support BGP then we would implement the l3vpn-base model and
l3vpn-bgp (which augments base). Customers can clearly see what we
support by looking at the netconf capabilities of our orchestration
system.

Apologies if I missed something in the model, it's a year ago since I
read it and I've only skimmed through the latest revision.

Kind regards,
      Kristian.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 19 Apr 2016 11:12:25 +0900

Hi All,

>Should we declare deviations? I suppose we can always return an error when the customer sends this to us, but that's not very elegant to do 
>in a model driven world. Introducing if-feature into the model would perhaps be one way, or that the model be carved up into many smaller 
>models that augments base model, for example:

In my understanding, the deviation suits this.
(If-)feature is used for a conditional case, ex.) an equipment in a network supports both BGP and OSPF, but another one in the same network can support only BGP.

Conformance for the deviation can be checked in the negotiation phase, before a customer send an actual service activation request.
https://tools.ietf.org/html/rfc6020#section-5.6.4
This is out of scope for each data model, but the transport protocol or YANG should consider this (and is already considered).

Am I missing something?

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Monday, April 18, 2016 7:44 PM
To: [email-masked]
Cc: Ian Farrer; 'Mikael Abrahamsson'; [email-masked]; Zoric, Sladjana; [email-masked]
Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

Dear all,

Regards, Benoit

Benoit,

in my head this model is used not only as an internal representation but also to allow a customer to manage a L3VPN that we (or someone else) provides. I wonder how we as the provider can limit the amount of features that we support. The model includes RIP, OSPF and BGP as PE-CE protocols. There are multicast portions in there and so forth. If we choose to only provide BGP as routing protocol, how can we signal this to the customer? Should we declare deviations? I suppose we can always return an error when the customer sends this to us, but that's not very elegant to do in a model driven world. Introducing if-feature into the model would perhaps be one way, or that the model be carved up into many smaller models that augments base model, for example:
    - l3vpn-base
    - l3vpn-bgp
    - l3vpn-rip
    - l3vpn-ospf

If we only support BGP then we would implement the l3vpn-base model and l3vpn-bgp (which augments base). Customers can clearly see what we support by looking at the netconf capabilities of our orchestration system.

Apologies if I missed something in the model, it's a year ago since I read it and I've only skimmed through the latest revision.

Kind regards,
      Kristian.

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

---

From: wangzitao <[email-masked]>
Date: Tue, 19 Apr 2016 03:31:37 +0000

Hi All,

IMHO, there are already some conditional statements like:

                container ospf {
                    when "../type = 'ospf'" {
                        description
                         "Only applies
                         when protocol is OSPF.";
                    }
                    ...
                container bgp {
                    when "../type = 'bgp'" {
                        description
                         "Only applies when
                         protocol is BGP.";
                    }
                    ...
The when statement can restrain the ospf/bgp container. If not satisfied the "when" statement, the ospf/bgp container is invalid.
"The node defined by the parent data definition statement is only valid when the condition specified by the "when"
statement is satisfied."[rfc6020#section-7.19.5.]

Best Regards!
-Michael(TAO)

-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年4月19日 10:12
收件人: 'Benoit Claise'; [email-masked]
抄送: [email-masked]; [email-masked]; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
主题: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

Hi All,

>Should we declare deviations? I suppose we can always return an error 
>when the customer sends this to us, but that's not very elegant to do 
>in a model driven world. Introducing if-feature into the model would perhaps be one way, or that the model be carved up into many smaller models that augments base model, for example:

Am I missing something?

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Monday, April 18, 2016 7:44 PM
To: [email-masked]
Cc: Ian Farrer; 'Mikael Abrahamsson'; [email-masked]; Zoric, Sladjana; [email-masked]
Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

Dear all,

Regards, Benoit

Benoit,

Kind regards,
      Kristian.

---

From: <[email-masked]>
Date: Tue, 19 Apr 2016 07:33:47 +0000

Yep, deviation looks the good way to do.
As for device config, if a device does not support a config statement, it advertises a deviation. Same thing here ...

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, April 19, 2016 04:12
To: 'Benoit Claise'; [email-masked]
Cc: [email-masked]; [email-masked]; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

Hi All,

Am I missing something?

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Monday, April 18, 2016 7:44 PM
To: [email-masked]
Cc: Ian Farrer; 'Mikael Abrahamsson'; [email-masked]; Zoric, Sladjana; [email-masked]
Subject: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

Dear all,

Regards, Benoit

Benoit,

Kind regards,
      Kristian.

_________________________________________________________________________________________________________________________

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: Kristian Larsson <[email-masked]>
Date: Tue, 19 Apr 2016 09:55:10 +0200

On 19/04/16 04:12, Ogaki, Kenichi wrote:
> Hi All,
>
>> Should we declare deviations? I suppose we can always return an
>> error when the customer sends this to us, but that's not very
>> elegant to do in a model driven world. Introducing if-feature into
>> the model would perhaps be one way, or that the model be carved up
>> into many smaller models that augments base model, for example:
>
> In my understanding, the deviation suits this. (If-)feature is used
> for a conditional case, ex.) an equipment in a network supports both
> BGP and OSPF, but another one in the same network can support only
> BGP.

With that explanation I think if-feature is just as good a fit, if not 
better, than deviations.

> Conformance for the deviation can be checked in the negotiation
> phase, before a customer send an actual service activation request.
> https://tools.ietf.org/html/rfc6020#section-5.6.4 This is out of
> scope for each data model, but the transport protocol or YANG should
> consider this (and is already considered).
>
> Am I missing something?

One problem I see with deviations is that I believe there is no clean 
standardised way of defining them. Let's say there are 10 L3VPN 
providers out there that all define that BGP is the only PE-CE protocol 
support and no multicast. How many different deviations will we see? 1? 10?

The normal case here isn't to support the full model. I doubt anyone 
actually will, so I think it's a bit backwards to define the model with 
all features and then expect people to use deviations.

I think it's a lot cleaner for a customer to look at NETCONF 
capabilities and see l3vpn-base & l3vpn-bgp to understand the provider 
only supports BGP as PE-CE protocol, compared to parsing deviation 
files. if-feature would also be easier to look at than deviation.

    kll

> -----Original Message----- From: L3sm [mailto:[email-masked]]
> On Behalf Of Benoit Claise Sent: Monday, April 18, 2016 7:44 PM To:
> [email-masked] Cc: Ian Farrer; 'Mikael Abrahamsson';
> [email-masked]; Zoric, Sladjana;
> [email-masked] Subject: [L3sm] Feedback on
> draft-ietf-l3sm-l3vpn-service-model
>
> Dear all,
>
> in my head this model is used not only as an internal representation
> but also to allow a customer to manage a L3VPN that we (or someone
> else) provides. I wonder how we as the provider can limit the amount
> of features that we support. The model includes RIP, OSPF and BGP as
> PE-CE protocols. There are multicast portions in there and so forth.
> If we choose to only provide BGP as routing protocol, how can we
> signal this to the customer? Should we declare deviations? I suppose
> we can always return an error when the customer sends this to us, but
> that's not very elegant to do in a model driven world. Introducing
> if-feature into the model would perhaps be one way, or that the model
> be carved up into many smaller models that augments base model, for
> example: - l3vpn-base - l3vpn-bgp - l3vpn-rip - l3vpn-ospf
>
> If we only support BGP then we would implement the l3vpn-base model
> and l3vpn-bgp (which augments base). Customers can clearly see what
> we support by looking at the netconf capabilities of our
> orchestration system.
>
> Kind regards, Kristian.
> _______________________________________________ L3sm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/l3sm
>

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 19 Apr 2016 09:57:40 +0200

On 19/04/16 09:33, [email-masked] wrote:
> Yep, deviation looks the good way to do. As for device config, if a
> device does not support a config statement, it advertises a
> deviation. Same thing here ...

Or the model is built with if-features so the device can cleanly 
announce what it supports.

    kll

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Apr 2016 10:53:31 +0200 (CEST)

>From a pure YANG perspective, if-features are better in this case than
deviations.  Features should be used when you define "conformance
profiles" at model design time.  Deviations are used *by specific
implementations* when they fail to implement a specific conformance
profile.

/martin

---

From: <[email-masked]>
Date: Tue, 19 Apr 2016 10:13:28 +0000

The main issue with features is to define what should be a feature , and what is in the base and I'm afraid that we could fall in infinite discussions.

-----Original Message-----
From: Kristian Larsson [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2016 09:58
To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; [email-masked]
Cc: [email-masked]; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

On 19/04/16 09:33, [email-masked] wrote:
> device does not support a config statement, it advertises a deviation. 
> Same thing here ...

Or the model is built with if-features so the device can cleanly announce what it supports.

    kll

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 19 Apr 2016 06:53:54 +0000

On 19/04/16 05:31, wangzitao wrote:
> The when statement can restrain the ospf/bgp container. If not
satisfied the "when" statement, the ospf/bgp container is invalid.
> "The node defined by the parent data definition statement is only
valid when the condition specified by the "when"
> statement is satisfied."[rfc6020#section-7.19.5.]

"../type" is filled out by the customer and not by the provider (me) so 
I don't this is applicable. It's only to keep consistency within the 
model - doesn't limit instance data input for the ../type

    kll

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 19 Apr 2016 13:57:24 +0200

On 19/04/16 12:13, [email-masked] wrote:
> The main issue with features is to define what should be a feature ,
> and what is in the base and I'm afraid that we could fall in infinite
> discussions.

Okay, sure, I can see how that is a non-trivial discussion but it's 
certainly not an impossible one. Instead you are advocating for the 
extreme opposite and not have any if-features at all, which results in a 
model so big that I will have to spend more time writing a deviation 
file for it than it would take me to write a new model. Okay, I'm 
exaggerating a bit but virtually all providers will define a deviation 
which I think means the model is fundamentally broken. Having deviations 
shouldn't be the normal state.

Does Orange support all those PE-CE protocols? Do you do encryption? 
Will you not have any deviations?

Kind regards,
    Kristian.

---

From: <[email-masked]>
Date: Tue, 19 Apr 2016 12:17:03 +0000

Hi,

We will not support all containers of the model but most of them.

Now in term of model usage, two main usages :
- customer is using a portal to order the services, in this case there is no need to advertise any deviation, as the REST or Netconf client is also managed by the provider (client is the portal)
- Provider opens API to customers :
	- customer is able to use directly L3SM using REST or Netconf : deviations need to be advertised.

You will find attached a quick exercise (so I probably missed some) on what could be the features in the model tree. Features are identified between {}.
For some identities, we would need features : YANG 1.1 needed.
Just to start the discussion.

Best Regards,

Stephane

-----Original Message-----
From: Kristian Larsson [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2016 13:57
To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; [email-masked]
Cc: [email-masked]; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

> and what is in the base and I'm afraid that we could fall in infinite 

Okay, sure, I can see how that is a non-trivial discussion but it's certainly not an impossible one. Instead you are advocating for the extreme opposite and not have any if-features at all, which results in a model so big that I will have to spend more time writing a deviation file for it than it would take me to write a new model. Okay, I'm exaggerating a bit but virtually all providers will define a deviation which I think means the model is fundamentally broken. Having deviations shouldn't be the normal state.

Kind regards,
    Kristian.

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 19 Apr 2016 16:35:37 +0200

On 19/04/16 14:17, [email-masked] wrote:
> - customer is using a portal to order the services, in this case
> there is no need to advertise any deviation, as the REST or Netconf
> client is  also managed by the provider (client is the portal)

Right, I agree. I'm convinced the first model, with a pretty web UI will 
be the main interface but I'm hoping that the second model will gain 
some traction as well. With more FOSS tools around NC/RC/YANG it 
certainly could and why not eliminate one step of weakly modeled data. 
Often the customer has an internal structure for what they want, like 
addresses of all satellite offices, which they then convert to Excel and 
send to the provider who will convert it to something else. This model 
could remove those weakly modeled steps.

> Just to start the discussion.

Good start, I actually began looking at this but you were much faster. 
We have made almost the exact same choices :)

What is authentication used for? Seems to be an empty container.

    kll

---

From: <[email-masked]>
Date: Wed, 20 Apr 2016 07:42:21 +0000

> What is authentication used for? Seems to be an empty container.

We do not spend a lot of time on security part, so there is some adjustment to do.
The idea of authentication container was in case customer using an authenticated access type (PPP for example) and then could provide its own password.
The container was for the moment here just for augmentation purpose. But we can keep it, remove it, add more in, depending on feedback.

Thx

-----Original Message-----
From: Kristian Larsson [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2016 16:36
To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi; 'Benoit Claise'; [email-masked]
Cc: [email-masked]; 'Mikael Abrahamsson'; 'Ian Farrer'; 'Zoric, Sladjana'
Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

On 19/04/16 14:17, [email-masked] wrote:
> - customer is using a portal to order the services, in this case there 
> is no need to advertise any deviation, as the REST or Netconf client 
> is  also managed by the provider (client is the portal)

Right, I agree. I'm convinced the first model, with a pretty web UI will be the main interface but I'm hoping that the second model will gain some traction as well. With more FOSS tools around NC/RC/YANG it certainly could and why not eliminate one step of weakly modeled data. 
Often the customer has an internal structure for what they want, like addresses of all satellite offices, which they then convert to Excel and send to the provider who will convert it to something else. This model could remove those weakly modeled steps.

    kll

> ______________________________________________________________________
> ___________________________________________________
>
> 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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Apr 2016 14:18:05 +0100

IMHO the augmentation mechanism (empty container) is the right approach because
the options are very varied, customers will have very specific requirements, and
different operators will offer different services (but I am not an operator!).

Furthermore, it seems likely (to me) that the security augmentations that are
developed will be common across a number of services. That speaks in favour of
putting them in a separate (not L3SM-specific) model that can be pointed to from
this model.

Adrian

> From: L3sm [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 20 April 2016 08:42
> To: Kristian Larsson; Ogaki, Kenichi; 'Benoit Claise'; [email-masked]
> Cc: 'Zoric, Sladjana'; 'Mikael Abrahamsson'; 'Ian Farrer';
> [email-masked]
> The idea of authentication container was in case customer using an
authenticated
> access type (PPP for example) and then could provide its own password.
> The container was for the moment here just for augmentation purpose. But we
> can keep it, remove it, add more in, depending on feedback.
> 
> Thx
> 
> 
> > 	- customer is able to use directly L3SM using REST or Netconf :
deviations
> need to be advertised.
> 
> Right, I agree. I'm convinced the first model, with a pretty web UI will be
the main
> interface but I'm hoping that the second model will gain some traction as
well.
> With more FOSS tools around NC/RC/YANG it certainly could and why not
> eliminate one step of weakly modeled data.
addresses
> of all satellite offices, which they then convert to Excel and send to the
provider
> who will convert it to something else. This model could remove those weakly
> modeled steps.
> 
> 
> > You will find attached a quick exercise (so I probably missed some) on what
> could be the features in the model tree. Features are identified between {}.
certainly not an
> impossible one. Instead you are advocating for the extreme opposite and not
> have any if-features at all, which results in a model so big that I will have
to spend
> more time writing a deviation file for it than it would take me to write a new
> model. Okay, I'm exaggerating a bit but virtually all providers will define a
> deviation which I think means the model is fundamentally broken. Having
> deviations shouldn't be the normal state.
> >
> > 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.
> >
> > 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.
> ______________________________________________________________
> ___________________________________________________________
> 
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> If you have received this email in error, please notify the sender and delete
this
> message and its attachments.

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 20 Apr 2016 18:09:07 +0200

If the authentication container is purely for augmentation I don't think 
we need a "security" if-feature on the security container, instead I 
would opt for an "encryption" if-feature on the encryption container. If 
someone supports authentication then it will be augmented by another 
model and the lack of such model is a clear indicator that no 
authentication is supported.

As an native v6 only network I would like to see an if-feature for ipv4 :)

    kll

---

From: <[email-masked]>
Date: Thu, 21 Apr 2016 06:00:41 +0000

[SLI] LOL, agree , that looks acceptable ;)

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Kristian Larsson
Sent: Wednesday, April 20, 2016 18:09
To: [email-masked]
Subject: Re: [L3sm] Feedback on draft-ietf-l3sm-l3vpn-service-model

If the authentication container is purely for augmentation I don't think we need a "security" if-feature on the security container, instead I would opt for an "encryption" if-feature on the encryption container. If someone supports authentication then it will be augmented by another model and the lack of such model is a clear indicator that no authentication is supported.

    kll

On 20/04/16 09:42, [email-masked] wrote:
>>> and what is in the base and I'm afraid that we could fall in 
>>> infinite discussions.
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>