Re: [netmod] A reworking of RFC8343

Dmytro Shytyi <> Tue, 22 October 2019 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF93A1200E7 for <>; Tue, 22 Oct 2019 13:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wxTBZJg-B8xa for <>; Tue, 22 Oct 2019 13:28:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B77C01200F7 for <>; Tue, 22 Oct 2019 13:28:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1571776083; cv=none;; s=zohoarc; b=aRtb1ohV9IXxBBsNJqpIv6oobyXxxKzCBrluT+bnIYHXqDjSdgVVt/SXk49rdAL83CLABf5M5IMwwK0WzqBvdOPto74TUObvqO4Af3FB5lGyYvuKywDh36POI2FqDTIRyMWfLKHSgesPhBY4VE1lQXKLI3eimq3zhFJTC9U7t9s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1571776083; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=8bz3LOc93HLvfPcbzmy45exv6D1OP1JOMoiFhmPbR8w=; b=CehBP73szISHBm4m8bcIP5w/2fbBxPrV5mFIDsd80jJo4eJPjXGJHSAyaiqIK6StalmKUvT2m5VjR9yZ97AeiUNv5Dp2Dvk8fUAid8MV8QQl5SZmjQf63VsOv9HTWFsZIJK66id76UyIQAhRMwkr7e21mOU5scDVgxuCzMuruWw=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<> header.from=<>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1571776083; s=hs;;; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=14493; bh=8bz3LOc93HLvfPcbzmy45exv6D1OP1JOMoiFhmPbR8w=; b=TwLOqk0bDtA7l3blhQu1HZRFvXInqFjMP24hTmDiNpvY+lRTai6QmtT5q3MG2DdA 3lZy55hkofLnctllVIEQyJE2QmkdMgOZVIXwRWMAOaPfq6uR56y1iQSAcL8DHD5zprp vVm2Y74TubS9zC+e18QYupDR++e/w9+L1aekPx10=
Received: from by with SMTP id 1571776083213770.9449764950687; Tue, 22 Oct 2019 22:28:03 +0200 (CEST)
Date: Tue, 22 Oct 2019 22:28:03 +0200
From: Dmytro Shytyi <>
To: "\"Schönwälder, Jürgen\"" <>
Cc: Martin Bjorklund <>, netmod <>
Message-Id: <>
In-Reply-To: <>
References: <> <> <039001d588c2$bb3d7e20$> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_272731_1930145823.1571776083209"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <>
Subject: Re: [netmod] A reworking of RFC8343
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2019 20:28:17 -0000


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 

[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: 
> 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 
> 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 


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 



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;
             "Name of the connector";
         leaf link {
           type leafref {
             path "../../../../ietf-nfv:links/ietf-nfv:link";
             "Link that is connected to the port
              via connector";
           "Set of the connectors the physical
            interface has";
         "ucpe ports of the interface";


Juergen Schoenwaelder           Jacobs University Bremen gGmbH 
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany 
Fax:   +49 421 200 3103         <>