Re: [L2sm] L2SM charter proposal

["Scharf, Michael (Nokia - DE)" <[e-mail]>]

Inline (removing some text)...

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

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.

> 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

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.

> 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

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?

> 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

That is better.

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

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

Michael