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.
Joe
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
