Re: [L2sm] L2SM charter proposal

["Adrian Farrel" <[e-mail]>]

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.
>>>
>>> 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?
> 
> 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.
>>>
>>> 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.
[snip]
>> 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.
> 
> 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.

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

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

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

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