Subject: [L2sm] L2SM charter proposal

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 10 Oct 2016 12:27:10 +0000

I am not sure where the charter wording on https://datatracker.ietf.org/wg/l2sm/charter/ has been discussed. Anyway, I had a look...

> The IETF and the industry in general is currently specifying a set of YANG
> models for network element and protocol onfiguration. This is an essential first

Nit: s/onfiguration/configuration/

> step, but the end goal is full system configuration that enable service agility
> to speed service creation and delivery and allows the deployment of innovative
> new services across networks. Services are built from a combination of network
> element and protocol configuration, but are specified to service
> users in more abstract terms.

> The Layer Two Virtual Private Network Service Model (L2SM) working group is a
> short-lived WG tasked to create a YANG data model that describes a L2VPN service
> (a L2VPN service model) that can be used for communication between customers and

Isn't one of the lessons learnt from L3SM that the term "service model" can be understood in quite different ways, in particular in hierarchical network architectures?

> network operators, and to provide input to automated control and configuration
> applications. The working group will attempt to derive a single data model that
> includes support for point-to-point Virtual Private Wire Services (VPWS) and
> multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled
> using the Label Distribution Protocol (LDP) and the Border Gateway Protocol
> (BGP) as described in RFC4761 and RFC6624.

To me, "includes support for" is not a very specific wording. Will the deliverable of a working group be limited to VPWS and VPLS? If yes, why not state it? If no, why not be more explicit about what else may be in scope, or not in scope?

BTW, that long sentence is hard to parse.

> It needs to be clearly understood that this L2VPN service model is not an L2VPN
> configuration model. That is, it does not provide details for configuring
> network elements or protocols (that work is expected to be carried out in other
> protocol-specific working groups). Instead, the L2VPN service model contains the
> characteristics of the service as discussed between the operators and their
> customers. A separate process is responsible for mapping this service model onto
> the protocols and network elements depending on how the network operator chooses
> to realise the service.

> The deliverable from this working group will provide information to evaluate the
> set of YANG models that have already been developed or are under development,

That sentence is also in the L3SM charter. But I wonder if L3SM has indeed delivered an evaluation of existing YANG models? Also, I am not sure how draft-wen-l2sm-l2vpn-service-model addresses this requirement.

I believe for L2VPNs there are other ongoing modeling activities, e.g., in MEF, and there may also be overlap with some transport-oriented work in other IETF WGs. This sentence could be understood as an evaluation and gap analysis of existing YANG models.

> and will help identify any missing models or details. The deliverable can be
> viewed as driving requirements for protocol configuration model so that the
> service parameters can be mapped into inputs used by the protocol models.

Again, I wonder if this WG really plans to deliver this? Has L3SM really managed to provide good requirements for parameter mapping, e.g., for the non-trivial service parameters such as QoS?

> The working group will learn from the experience of the L3SM working group and
> it is expected that the L2SM data model will have similar structure to the L3SM
> data model.

I am not sure what the first part of this sentence would imply? Unless it is spelt out what these lessons learnt are, I think it can be removed. The charter wording of L2SM itself may obviously leverage lessons learnt from L3SM ;-)

The second part of the sentence results in quite a number of constraints regarding the model design. I think this warrants a dedicated sentence, and possibly even some further discussion on the priority of aligning structure with L3SM vs. aligning with other YANG models.

> The working group should consider draft-wen-l2sm-l2vpn-service-model as a
> starting point.

> The working group will coordinate with other working groups responsible for
> L2VPN protocol work (most notably with BESS and PALS) and with the MEF.

I think there is a difference between BESS/PALS and MEF. The models in BESS and PALS don't overlap significantly with the scope of the L2SM charter.

I think a more explicit statement regarding MEF would be useful. MEF works on quite related YANG models. For instance, draft-wen-l2sm-l2vpn-service-model includes the following sentence: "Rather than introducing a new set of terminologies, the L2SM will align with existing MEF attributes when it's applicable." That wording may be a starting point. Albeit the question is whether some sort of liaison would be limited to terminology reuse only.

Also, I wonder if MEF is really the only other relevant standardization body for L2VPNs.

>From an implementer's perspective, lack of alignment between standardization bodies is an issue.

> Milestones

> December 2016   Adopt WG draft for data model
> October  2017   Request publication of data model as Standards Track RFC
> December 2017   Close working group

Well, this seems a bit ambitious to me, given the experience in L3SM. And L3SM didn't have to consider e.g. other standardization bodies...

Thanks

Michael

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Oct 2016 09:55:38 +0100

Hello Michael,

> I am not sure where the charter wording on
> https://datatracker.ietf.org/wg/l2sm/charter/ has been discussed. Anyway, I
had
> a look...

Don't think it has. I think the creation of this list gives us all the chance,
and it seems like you took it correctly :-)

Looking at the status of the charter, it hasn't been to the IESG yet, and after
that it will go to the whole IETF. So now is not a bad time for discussions.

> > short-lived WG tasked to create a YANG data model that describes a L2VPN
> > service (a L2VPN service model) that can be used for communication between
> > customers and
> 
> Isn't one of the lessons learnt from L3SM that the term "service model" can be
> understood in quite different ways, in particular in hierarchical network
> architectures?

Yeah. You're right that there was a lot of discussion and confusion about what a
service model is.

Qin Wu, Will Liu, and I wrote draft-wu-opsawg-service-model-explained to try to
get some consensus around the different meanings. But that document is not a WG
document (yet?) and certainly can't claim to have consensus.

So I see the problem, but I don't see a solution. To me (of course) it is clear
what a "service model" is. Is there a form of words that you would find helpful
to scope the L2SM work to the same type of "service model" that L3SM addressed?

> To me, "includes support for" is not a very specific wording. Will the
deliverable of
> a working group be limited to VPWS and VPLS? If yes, why not state it? If no,
why
> not be more explicit about what else may be in scope, or not in scope?

I read this as:
- MUST include VPWS and VPLS
- MAY include other things

The text could be clearer. Which way would you like it to go: exclusive or
inclusive?

> BTW, that long sentence is hard to parse.

Agree.

> > The deliverable from this working group will provide information to evaluate
> > the set of YANG models that have already been developed or are under 
> > development,
> 
> That sentence is also in the L3SM charter. But I wonder if L3SM has indeed
> delivered an evaluation of existing YANG models? Also, I am not sure how
draft-
> wen-l2sm-l2vpn-service-model addresses this requirement.

Hmmm, I do not believe that L3SM was chartered to provide that evaluation.
Instead (and as you note, exactly as the text is proposed for L2SM) the charter
states:

|The deliverable from this working group will provide information to evaluate
the set of
|YANG models that have already been developed or are under development, and will
|help identify any missing models or details. The deliverable can be viewed as
driving 
|requirements for protocol configuration model so that the service parameters
can be
|mapped into inputs used by the protocol models.

I took this to mean that the L3SM could be used by those working on models
"lower down the stack" (such as in BESS, RTGWG, IDR, etc.) to see whether they
had captured all of the details that would be needed to deliver the services
that operators want to sell to customers.  Looked at another way, implementers
building automated service delivery systems (who might want to support L3SM or
some proprietary variant) would use L3SM to determine whether they could map a
customer's service request to the YANG models that are used within the network
to deliver the service.

I'm not aware of this work having been done in a public forum, however, since
there are implementations of L3SM, I assume that the work has been done and that
perhaps some of the changes proposed to other models over time have arisen have
come from this work.

> I believe for L2VPNs there are other ongoing modeling activities, e.g., in
MEF, and
> there may also be overlap with some transport-oriented work in other IETF WGs.
> This sentence could be understood as an evaluation and gap analysis of
existing
> YANG models.

I think that is exactly the correct understanding.
The question is, however, who does that gap analysis.
As I say, I don't think the L3SM WG was asked to do the analysis, and this
charter text is not asking a potential L2SM WG to do that.

Gap analyses are, IMHO, best done by the people who propose to fill the gaps not
by an "external authority" that might try to instruct someone else to fill the
gaps.

> Again, I wonder if this WG really plans to deliver this? Has L3SM really
managed to
> provide good requirements for parameter mapping, e.g., for the non-trivial
> service parameters such as QoS?

As above.

> > The working group will learn from the experience of the L3SM working group
> > and it is expected that the L2SM data model will have similar structure to
the
> > L3SM data model.
> 
> I am not sure what the first part of this sentence would imply? Unless it is
spelt
> out what these lessons learnt are, I think it can be removed. The charter
wording
> of L2SM itself may obviously leverage lessons learnt from L3SM ;-)
> 
> The second part of the sentence results in quite a number of constraints
> regarding the model design. I think this warrants a dedicated sentence, and
> possibly even some further discussion on the priority of aligning structure
with
> L3SM vs. aligning with other YANG models.

The benefits of aligning structure with L3SM would seem to be:
- a "service orchestrator" could use common or similar code
- customers will have familiarity across services
- there is future potential to generalise into a common service
   model 
- discussions that led to the L3SM structure are not repeated
   leading to more rapid development

Other models with which L2SM might align are presumably the service delivery
models being worked on in BESS. There is absolutely value in looking at these
models, but they are technology specific and it is risky to force the service as
offered by the operator to be too dependent on how the network is operated.
Orchestration and mapping will be required.

> I think there is a difference between BESS/PALS and MEF. The models in BESS
> and PALS don't overlap significantly with the scope of the L2SM charter.
> 
> I think a more explicit statement regarding MEF would be useful. MEF works on
> quite related YANG models. For instance, draft-wen-l2sm-l2vpn-service-model
> includes the following sentence: "Rather than introducing a new set of
> terminologies, the L2SM will align with existing MEF attributes when it's
> applicable." That wording may be a starting point. Albeit the question is
whether
> some sort of liaison would be limited to terminology reuse only.

I agree that the relationship with MEF will be very important.
Liaison relationships are created and maintained by the IAB.
In the absence of such a relationship a WG can only communicate and coordinate.

> Also, I wonder if MEF is really the only other relevant standardization body
for
> L2VPNs.

Ah, that's important.
Which other bodies or forums have you got in mind?

> Well, this seems a bit ambitious to me, given the experience in L3SM. And L3SM
> didn't have to consider e.g. other standardization bodies...

When have WG milestones ever not been ambitious? . 
But you make a good point. L3SM was close to its dates until it hit the tail. It
had a very long tail and I do know why except that perhaps the largest volume of
review comments didn't come until right at the end of the work - perhaps a
feature of caring about the output but not caring to contribute to the
development?

Anyway, that is my $0.02 to add to yours.
Hopefully the AD is listening.

Cheers,
Adrian

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 11 Oct 2016 11:18:24 +0000

Inline...

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2016 10:56 AM
> To: Scharf, Michael (Nokia - DE); [email-masked]
> Subject: RE: [L2sm] L2SM charter proposal
> 
> Hello Michael,
> 
> > > The Layer Two Virtual Private Network Service Model (L2SM) working group
> is
> a

I think the charter could use the term "customer service model". We can certainly argue whether this is the best term, but to me it is better than "service model". 

> The text could be clearer. Which way would you like it to go: exclusive or

I think a better alternative would be to list examples what MAY be included as well, provided there is WG consensus etc. But under the assumption that this WG shall be driven by operators, I suspect it is up to them to decide.

Potential implementations could probably deal with L2VPN services beyond VPWS and VPLS. Having a common base model could have benefits.

> perhaps some of the changes proposed to other models over time have arisen

If that sort of work is expected to happen outside the L2SM WG, I wonder why the charter needs wording on it.

Or if it is expected to happen inside the L2SM WG, maybe a process different to L3SM would be needed?

I may be fine either way but I think a charter should have clear wording.

> charter text is not asking a potential L2SM WG to do that.

For L2SM there are comparable modeling activities in other standardization bodies, in open source projects (e.g., for orchestrators), etc. When L3SM was chartered, I think related work was less mature. So, the situation regarding a gap analysis is not exactly the same.

I think the charter should clearly explain whether a gap analysis is to be performed by the WG, or not. If the WG is not asked to perform a gap analysis, I think the charter wording can be cleaned up accordingly.
 
>    leading to more rapid development

I agree that there could be benefits and therefore I think this design objective should be stressed. BTW, this argument does not apply to VPWS and VPLS only, as orchestrators may not be limited to that sort of services only.

> Which other bodies or forums have you got in mind?

I don't follow IEEE and BBF, but both have Ethernet YANG modeling activities. Couldn't this matter?

And, as far as I know, MEF has liaisons with TMF, ONF, ITU-T, etc. on customer service models. Is there no need to look into this?

As L2VPNs are covered by multiple organizations, I'd really like to understand how the IAB plans to handle this. Wouldn't a charter be a good place to provide some guidance to the WG?

> feature of caring about the output but not caring to contribute to the

This is normal WG business. I am more concerned about the impact of external dependencies.

Michael

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Oct 2016 14:43:03 +0100

Hi again, Michael,

Now that the IESG has sent out asking for comments on the charter, I wanted to
make sure we don't lose your input from this thread.

> I think the charter could use the term "customer service model". We can
certainly
> argue whether this is the best term, but to me it is better than "service
model".

Yup, I can agree with that.
Although draft-wu-opsawg-service-model-explained can't claim consensus, I hope
that this term is less ambiguous and slightly more focused.

>>>> applications. The working group will attempt to derive a single data model
>>>> that includes support for point-to-point Virtual Private Wire Services
>>>> (VPWS) and multipoint Virtual Private LAN services (VPLS) that use
>>>> Pseudowires signaled using the Label Distribution Protocol (LDP) and
>>>> the Border Gateway Protocol (BGP) as described in RFC4761 and
>>>> RFC6624.
>>>
>>> deliverable of a working group be limited to VPWS and VPLS? If yes,
>>> why not state it? If no, why not be more explicit about what else may
>>> be in scope, or not in scope?
>>
>> I read this as:
> I think a better alternative would be to list examples what MAY be included as
> well, provided there is WG consensus etc. But under the assumption that this
WG
> shall be driven by operators, I suspect it is up to them to decide.
> 
> Potential implementations could probably deal with L2VPN services beyond
> VPWS and VPLS. Having a common base model could have benefits.

I think Alia had a similar take-away in IESG review as she wanted to add EVPN to
the list of service types covered in the charter (it is already in the draft).

I see that Benoit has updated the text to...

==
The Layer Two Virtual Private Network Service Model (L2SM) working group is a
short-lived WG tasked to create a YANG data model that describes a L2VPN service
(a L2VPN service model) that can be used for communication between customers and
network operators, and to provide input to automated control and configuration
applications. The working group will attempt to derive a single data model that
includes support for point-to-point Virtual Private Wire Services (VPWS),
multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled
using the Label Distribution Protocol (LDP) and the Border Gateway Protocol
(BGP) as described in RFC4761 and RFC6624, and Ethernet VPNs in RFC 7432.
==

I would suggest we pick up both of your points and re-work as...

==
The Layer Two Virtual Private Network Service Model (L2SM) working group is a
short-lived WG. It is tasked to create a YANG data model that describes a L2VPN
service (a L2VPN customer service model). The model can be used for
communication between customers and network operators, and to provide input to
automated control and configuration applications. 

It is recognized it would be beneficial to have a common base model that
addresses multiple popular L2VPN service types. The working group will attempt
to derive a single data model that includes support for point-to-point Virtual
Private Wire Services (VPWS), multipoint Virtual Private LAN services (VPLS)
that use Pseudowires signaled using the Label Distribution Protocol (LDP) and
the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624, and
Ethernet VPNs in RFC 7432. Other L2VPN service types may be included if there is
consensus in the working group.
==

>>>> The deliverable from this working group will provide information to
>>>> evaluate the set of YANG models that have already been developed
>>>> or are under development, and will help identify any missing models
>>>> or details. The deliverable can be viewed as driving requirements for
>>>> protocol configuration model so that the service parameters can be
>>>> mapped into inputs used by the protocol models.
>>>
>>> draft-wen-l2sm-l2vpn-service-model addresses this requirement.
>>
[snip]
>> "lower down the stack" (such as in BESS, RTGWG, IDR, etc.) to see whether
>> they had captured all of the details that would be needed to deliver the
>> services that operators want to sell to customers.  Looked at another way,
>> implementers building automated service delivery systems (who might
>> want to support L3SM or some proprietary variant) would use L3SM to
>> determine whether they could map a customer's service request to the
>> YANG models that are used within the network to deliver the service.
>>
>> there are implementations of L3SM, I assume that the work has been done and
>> that perhaps some of the changes proposed to other models over time have
>> arisen have come from this work.
> 
> Or if it is expected to happen inside the L2SM WG, maybe a process different
to
> L3SM would be needed?

How about...

OLD
The deliverable from this working group will provide information to evaluate the
set of YANG models that have already been developed or are under development,
and will help identify any missing models or details. The deliverable can be
viewed as driving requirements for protocol configuration model so that the
service parameters can be mapped into inputs used by the protocol models.
NEW
The deliverable from this working group will provide information that other
working groups can use to evaluate the set of YANG models that they have already
developed or that are under development. This will help them to identify any
missing models or details. Thus, the deliverable can be viewed as driving
requirements for service delivery models so that the customer service parameters
can be mapped into inputs used by the protocol configuration models.
END

>>> MEF, and there may also be overlap with some transport-oriented work
>>> in other IETF WGs.
>>> existing YANG models.
> For L2SM there are comparable modeling activities in other standardization
> bodies, in open source projects (e.g., for orchestrators), etc. When L3SM was
> chartered, I think related work was less mature. So, the situation regarding a
gap
> analysis is not exactly the same.
> 
> I think the charter should clearly explain whether a gap analysis is to be
> performed by the WG, or not. If the WG is not asked to perform a gap analysis,
I
> think the charter wording can be cleaned up accordingly.

Personally, I still like "coordinate" as a word to describe what a WG should
attempt to do. I think formal gap analysis work often degrades into a beauty
contest.

But we could...
OLD
The working group will coordinate with other working groups responsible for
L2VPN protocol work (most notably with BESS and PALS) and with the MEF.
NEW
The working group will coordinate with other working groups responsible for
L2VPN protocol work (most notably with BESS and PALS). It will also coordinate
with other organizations working on related L2VPN data models (such as the MEF).
END

>>>> The working group will learn from the experience of the L3SM working
>>>> group and it is expected that the L2SM data model will have similar
>>>> structure to the L3SM data model.
>>>
>>> spelt out what these lessons learnt are, I think it can be removed. The 
>>> charter wording of L2SM itself may obviously leverage lessons learnt from
>>> L3SM ;-)

It reduces to "harmless", I think. And if it makes the AD happy...  :-)

>>> with L3SM vs. aligning with other YANG models.
>>
> I agree that there could be benefits and therefore I think this design
objective
> should be stressed. BTW, this argument does not apply to VPWS and VPLS only,
> as orchestrators may not be limited to that sort of services only.

So, perhaps...
OLD
...and it is expected that the L2SM data model will have similar structure to
the L3SM data model.
NEW
... . It is expected that the L2SM data model will have similar structure to the
L3SM data model to enable benefits of common code, provide shared user
experience, and leverage discussions that took place during the L3SM
development.
END

[snip]

> As L2VPNs are covered by multiple organizations, I'd really like to understand
> how the IAB plans to handle this. Wouldn't a charter be a good place to
provide
> some guidance to the WG?

Hopefully addressed by my suggestion above.

Cheers,
Adrian

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 18 Oct 2016 11:13:05 +0000

Inline (removing some text)...

> service
> that

That wording seems better to me. Albeit the sentence is still long. To me, "described/specified/standardized in RFC 7432" would be easier to parse.

BTW, I believe that a charter is allowed to include bullet lists and this looks like a good candidate to me.

> can be mapped into inputs used by the protocol configuration models.

In practice, a customer service model is much more abstract than specific configuration models, i.e., it only includes a subset of parameters. It seems a bit strange to me that the charter assumes that missing model details in protocol configuration will be derived from an abstract representation. And I am not sure if this has ever happened in the L3SM case.

In my experience, the real-world question is whether a customer service model indeed includes all the relevant parameters e.g. from a protocol configuration model, e.g., if a customer of a service provider has specific needs. This is exactly the opposite of the workflow that is assumed in the charter.

Of course, it doesn't do harm to make void statements.

> with other organizations working on related L2VPN data models (such as the

Noting external dependencies in a separate sentence is better.

Do the WG proponents plan to share details on how they plan to deal with the overlapping work in MEF?

> experience, and leverage discussions that took place during the L3SM

That is better.

> Hopefully addressed by my suggestion above.

I still don't understand how this relates to MEF and I suspect that question is pretty obvious.

Michael

---

From: Benoit Claise <[email-masked]>
Date: Wed, 19 Oct 2016 17:54:50 +0200

Michael, Adrian,

Thank you for the discussion, and the text proposal.
That lead to this new charter text, v00-05: 
https://datatracker.ietf.org/doc/charter-ietf-l2sm/
See in line (removing some text)...
> In practice, a customer service model is much more abstract than specific configuration models, i.e., it only includes a subset of parameters. It seems a bit strange to me that the charter assumes…
If we look at the L3SM customer service model, we can deduce which 
technologies  orchestrator/controller will have to configure on devices: 
routing, interface, multicast, etc. This is the idea behind this text. 
Note that it doesn't have to be a formal WG deliverable.
> Do the WG proponents plan to share details on how they plan to deal with the overlapping work in MEF?
That's a good questions for the draft authors.
 From a process point of view, the communication with MEF started.

Regards, Benoit