Hello,
On Tue, Oct 22, 2019 at 09:53:42PM +0200, Dmytro Shytyi wrote:
> Hello Martin,
>
>
>
> We are interested in some specific functionality provided by RFC 8343 yang
> model.
>
> So we derivied the yang model from RFC 8343, modified it and gave module name
> , prefix with some modifications like "ucpe-interfaces",
>
> but in description we kept the reference to original RFC(in future we wil
> modify the description to say that it is not original RFC 8343 yang module..)
>
> IMHO it is wrong to not presice in the description(reference) of the module /
> RFC that was we find usefull in our work.
>
>
>
> >Clearly unacceptable. Unclear why a ucpe can't implement
>
> ietf-interfaces from RFC 8343.
> I will try to give some ideas here.
>
>
>
> 1. uCPE phy interface has "vPorts" to witch "vLinks are assigned". "vLinks
> "connect" the phy interface with "vPort" of vswitch. Thus we may add to the
> derieved from RFC 8343 module the list of "vPorts" for each phy interface.
>
> example with 1 phy interface:
>
>
>
> +-------------------------------------
>
> | UCPE
>
> +------------+
>
> | |------vPort
> 1---vlink---(vport_sw)vswitch(vport_sw)--vlink---.....----WAN
>
> LAN----| Phy |------vPort 2
>
> | interface |
>
> +-------------+
>
> |
>
> +----------------------------------------------
You can augment a model without having to copy it. Whether your
augmentation makes sense I can't tell, not also that interface can be
layered.
[Dmytro] Yes I agree, it is exatly what we did in the
draft-shytyi-opsawg-vysm-04. We augmented "vPorts" to the interfaces :)
> 2. If we include the yang module from the RFC 8343 to the set of yang models
> by default it goes in the root of config mode. i.e:
>
> EXAMPLE:
>
> config t
>
> interfaces interface....
>
>
>
> When we have a parent module we need to place the RFC 8343 module to under
> the parent module (like in the draft draft-shytyi-opsawg-vysm-04).
>
> Hence the RFC8343 may be modified to add the augment statement(as it is dome
> in draft-shytyi-opsawg-vysm-04) to put the "interfaces interface" under the
> parent module like
>
> EXAMPLE:
> conifg t
>
> ucpe "ucpe X" interfaces interface...
Cut and paste to change the 'nesting' is _not_ proper usage of
YANG. The value of YANG is that objects with the same semantics are
predictable, this gives you interoperability. By copying modules to
other places (and tweaking semantics), you break the interoperability
promise.
/js
[Dmytro].
I find the task much easier if we could just augment the interfaces module
without changing it. I see it the next way . The "ietf-interfaces" yang module
initially was created for the config, when you have:
config t
interfaces interface ...
Here we have different condition of "nesting"... when module
"ucpe-ietf-interfaces" (not "ietf-interfaces") shout augment another module
("ietf-ucpe")
We augment vPorts to phy interfaces.
>Cut and paste to change the 'nesting' is _not_ proper usage of
YANG.
[Dmytro]
If I understood correctly I can't just derive the parts from the exisiting
module (by referencing them) to the new module.
So I have two questions:
If i cant derive the parts from existing module while creating a new, how to
address this issue(when we want "ucpe-ietf-interfaces" to augment "ietf-ucpe").
Could you suggest something?
So the here I have a question: How we will resolve the leafref in the
draft-shytyi-opsawg-vysm-04. if we will not do the augmentation of "ietf-ucpe"
in the ""ucpe-ietf-interfaces?
augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {
list ports {
key "port";
leaf port {
type string;
description
"Name of the connector";
}
leaf link {
type leafref {
path "../../../../ietf-nfv:links/ietf-nfv:link";
}
description
"Link that is connected to the port
via connector";
}
description
"Set of the connectors the physical
interface has";
}
description
"ucpe ports of the interface";
}
}
Thanks!
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
