Hello,
>[since you sent the same email to two WGs, I have added both to Cc in
>this reply. i don't think we should have parallell discussions in
>different MLs]
Dmytro Shytyi <mailto:[email protected]> wrote:
> Hello Jurgen,
>
>
>
> Thank you for your comment,
>
>
>
> Yeap I think it is a great idea to explain why do we need the adjustments of
> RFC 8343 in the case of draft-shytyi-opsawg-vysm-04.
>
>
>
> What do you think about this:
>
> 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.
>>You should use "augment" if you want to add additional nodes to an
>>existing module.
[Dmytro] Yes I agree, it is exatly what we did in the
draft-shytyi-opsawg-vysm-04. We augmented "vPorts" to the interfaces :)
The same "augment i think it could be appropriate to use in the derived module
from "ietf-interfaces" (RFC 8343) to agment the yang model "ietf-ucpe"
> example with 1 phy interface:
>
>
>
> +-------------------------------------
>
> | UCPE
>
> +------------+
>
> | |------vPort
> 1---vlink---(vport_sw)vswitch(vport_sw)--vlink---.....----WAN
>
> LAN----| Phy |------vPort 2
>
> | interface |
>
> +-------------+
>
> |
>
> +----------------------------------------------
>
> 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).
>Have you looked at the models in RFC 8529 and RFC 8530? Perhaps you
>can use them, rather than creating another special module for this
>particular use case?
[Dmytro] Thank you for this suggestion, @Martin.
I can imagine that we could assing "ietf-interfaces" to VSI as described in
the RFC 8529. @Martin, looging the schema of yang models for rfc 8529(below)
can we assign more than one (>1) LNE to the interface (both for rfc 8529 and
8530)?
In the uCPE usecase you may have multiple swithes assigned to the same port..
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)
+--:(vrf-root)
| +--mp vrf-root
+--:(vsi-root)
| +--mp vsi-root
+--:(vv-root)
+--mp vv-root
module: ietf-interfaces
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw ip:ipv4!
| | +--rw ip:enabled? boolean
| | +--rw ip:forwarding? boolean
| | +--rw ip:mtu? uint16
| | +--rw ip:address* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw (ip:subnet)
| | | +--:(ip:prefix-length)
| | | | +--rw ip:prefix-length? uint8
| | | +--:(ip:netmask)
| | | +--rw ip:netmask? yang:dotted-quad
| | +--rw ip:neighbor* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw ip:link-layer-address yang:phys-address
| | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string
/martin
On Tue, Oct 22, 2019 at 10:28:03PM +0200, Dmytro Shytyi wrote:
>
> 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.
>I do not understand your explanation. The ietf-interfaces hierarchy can
>be found on page 5 of RFC 8343. You can augment additional nodes into
>it.
[Dmytro] Yes we can augment additional nodes into "ietf-interfaces" it is what
we do in the draft-shytyi-opsawg-vysm-04 :
augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {
list ports {
key "port";
leaf port {
type string;
description
"Name of the connector";
}
We wold like to have this:
module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
+--rw ietf-ucpe:Name string
|
+--rw ucpe-if: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.
>
I have no idea what you mean with "(by referencing them) to the new
module". You can of course refer to definitions in ietf-interfaces.
> 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?
>I likely do not understand but you can of course augment
>ietf-interfaces with additional nodes that refer to ietf-ucpe
>definitions if that is what you are looking for.
[Dmytro] Yes we can augment the "ietf-interfaces" with new modules. Hovewer in
the draft-shytyi-opsawg-vysm-04 we are looking to augment module "ietf-ucpe"
with modified "ietf-interfaces". Example
SCHEME #1
module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
+--rw ietf-ucpe:Name string
|
+--rw ucpe-if:interfaces
....
To have a result similar to the scheme#1 (above) we derived the
"ietf-interfaces" to "ietf-ucpe-interfaces". And "ietf-ucpe-interfaces" was
modified (ex. with augment statement,etc..):
module ietf-ucpe-interfaces {
import ietf-ucpe { prefix ietf-vysm; }
...
augment "/ietf-vysm:ucpe"{
container interfaces {
description "Interface parameters.";
list interface {
...
}
}
}
If i cant derive the parts from existing module (ietf-interfaces) while
creating a new("ietf-ucpe-interfaces) how we can get the result similar to
scheme#1?
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";
> }
> }
>I think it is possible to have a path contraint on a leafref that
>refers to definitions in other modules (see the ABNF definition
>path-arg which resolves to absolute-path and relative-path and
>descendant-path and in there you find node-identifier which can carry
>an optional prefix that allows to refer to definitions in other
>namespaces).
/js
--
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/>_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
