Re: [Netmod-ver-dt] Resolving package conflicts

[Mahesh Jethanandani <[e-mail]>]

I have no objection either. But I want to take a very specific example, something I am already working on. With the package concept, how do you see this being packaged?

To support ietf-bgp model, I need the following modules:
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
To support ietf-evpn module, I need the following modules:
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
To support ietf-l2vpn module, I need the following modules:
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
There are some common modules that all three need, e.g. ietf-interfaces, ietf-ip etc., then there are modules like ietf-l2vpn that are the L2VPN “package” but are needed by EVPN, and then there will be modules that are needed by two of them for which I do not have an example here, but I am sure I can dig one up.

How do you see this packaged?

> On Sep 11, 2019, at 1:49 PM, Reshad Rahman (rrahman) <[e-mail]> wrote:
> 
> No objections, makes sense.
>  
> From: Netmod-ver-dt <[e-mail] <mailto:[e-mail]>> on behalf of "Rob Wilton (rwilton)" <[e-mail] <mailto:[e-mail]>>
> Date: Wednesday, September 11, 2019 at 6:00 AM
> To: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: [Netmod-ver-dt] Resolving package conflicts
>  
> In the packages draft it is possible to for a package definition to combine modules from two separate packages which may conflict.  I.e. more than one version of a module might end up in the resultant package, or the import dependencies might need to be fixed.
>  
> This is OK, because the packages draft requires that these conflicts are always explicitly resolved by listing the specific module versions in the combined package, so the problem is solved.
>  
> But what about if we define a package ietf-base@1.0.0 <mailto:ietf-base@1.0.0> that contains, say, 10 modules?
>  
> This package might be imported by a hypothetical ietf-routing@1.0.0 <mailto:ietf-routing@1.0.0>.
>  
> Separately there might be a hypothetical ietf-l2vpn@1.0.0 <mailto:ietf-l2vpn@1.0.0> package that has been published later and uses an updated version of ietf-base package, say ietf-base@1.5.0 <mailto:ietf-base@1.5.0>, that may contain BC updates to several of the modules.
>  
> Say a device wants to implement a my-packages@0.5.0 <mailto:my-packages@0.5.0> module that imports both ietf-routing@1.0.0 <mailto:ietf-routing@1.0.0>and ietf-l2vpn@1..0.0 <mailto:ietf-l2vpn@1.0.0>.  Currently the packages draft would require the my-packages definition to explicitly re-state each of the modules in ietf-base@1.5.0 <mailto:ietf-base@1.5.0> that differed ietf-base@1.0.0 <mailto:ietf-base@1.0.0> (because only a single version of a module can be implemented, and all conflicts must be explicitly resolved).
>  
> This works, but I’m wondering whether that might become overly verbose.  Hence, I’m thinking that it might be useful for the my-packages@0.5.0 <mailto:my-packages@0.5.0> definition to explicitly list ietf-base@1.5.0 <mailto:ietf-base@1.5.0> as a direct package import, stating that it is replacing ietf-base@1.0.0 <mailto:ietf-base@1.0.0> (which is indirectly imported via ietf-routing@1.0.0 <mailto:ietf-routing@1.0.0>).  Avoiding the need to explicitly list the conflicting modules.  In fact, we could require that all conflicting imported package versions must also be explicitly resolved, just like for modules.
>  
> Does anyone have any objections to this?
>  
> Thanks,
> Rob
>  
>  
> _______________________________________________
> Netmod-ver-dt mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt <https://www.ietf.org/mailman/listinfo/netmod-ver-dt>
Mahesh Jethanandani
[e-mail]