Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

[Oscar González de Dios <[e-mail]>]

Hi Tom,

>>The four documents are not spelled out but referred to in shorthand and while I think I know which are intended, that IMHO needs spelling out.

The involved modules which could potentially share a common Yang service types are:

- L3 VPN Customer Service YANG Model (L3SM) https://datatracker.ietf.org/doc/rfc8299/
- L2 VPN Customer Service YANG Model (L2SM)  https://datatracker.ietf.org/doc/rfc8466/
- L3 VPN Service Network Model (L3NM) https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-03
- L2 VPN Service Network Model (L2NM) https://tools.ietf.org/html/draft-barguil-opsawg-l2sm-l2nm-02


Best Regards,


Oscar

-----Mensaje original-----
De: tom petch <[e-mail]>
Enviado el: martes, 26 de mayo de 2020 18:05
Para: Joe Clarke (jclarke) <jclarke=[e-mail]>; Oscar González de Dios <[e-mail]>
CC: opsawg <[e-mail]>
Asunto: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

From: OPSAWG <[e-mail]> on behalf of Joe Clarke (jclarke) <jclarke=[e-mail]>
Sent: 21 May 2020 15:43



2. L3NM
    Revision of the three main issues:
Implementation Report by Cisco. It has two main issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110)
- Common module to have all the L3NM specific requirements. Type-like module.
[Anton]: It makes implementation simpler. Does not generate unnecessary dependencies
[Adrian]: It depends on if we need module for specific types, to avoid unnecessary imports. Also don't you only need to import types, not the entire module?
[Qin]: With L3SM we did not take an augmentation approach. If there are common types defined in both models, then we may need to find the common components. We should decouple of L3SM.
[Sriram]: Prefer to have a separate type-file for the specific parameters.
[Oscar]: Define a common type-file for the service models.
[Qin]: Is it possible to manage it as an independent draft?

[Oscar in github issues]: After the discussions, it seems reasonable to have a separate Yang module to contain the types. The suggestion is to write the module to cover the four service models (client service models, l3sm, l2sm and Network service models, l2nm, l3nm). It seems reasonable to include this module in l3nm draft instead of creating a new one to avoid dependencies.
Samier, Dan and Anton to collaborate for a first version of the split

As chair, I want to call this out since it sounds like the authors made a decision here, and I want to make sure the whole WG has a chance to weigh in.  In reading these minutes and issue #110, I can see the value of a types module to avoid what may be confusing imports, but I want to know if anyone on the WG has a different opinion.

<tp>
Joe
The four documents are not spelled out but referred to in shorthand and while I think I know which are intended, that IMHO needs spelling out.
In principle, a common types is a no-brainer provided it is done early enough - before anything becomes an RFC! - and with limited enough scope.  NETMOD got it right but did have decades of SMI experience to go on, RTGWG got it right, with TEAS it is less clear while layer0-types has changed much over its short life - is it right now? May be.
So carving out the current types (etc) will likely lead to a bad outcome; it is a question of looking carefully across the range of documents to see what is, or is likely to be common.  The higher up the stack you go the more likely items are to be common but equally the more likely it is that someone has been there already.
And if you look at existing types modules, it took a while for the penny to drop but they end up as separate I-D, better still with a different author to the importing I-D; a no brainer really.

Tom Petch

Joe


________________________________

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