Re: [i2rs] network-type: container vs. identity?

"Zhangxian (Xian)" <zhang.xian@huawei.com> Tue, 12 July 2016 15:17 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA1E12DA25 for <i2rs@ietfa.amsl.com>; Tue, 12 Jul 2016 08:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level:
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZIzb1l_aT7L for <i2rs@ietfa.amsl.com>; Tue, 12 Jul 2016 08:17:39 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F8A12DF19 for <i2rs@ietf.org>; Tue, 12 Jul 2016 07:49:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSL42739; Tue, 12 Jul 2016 14:49:29 +0000 (GMT)
Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jul 2016 15:49:28 +0100
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.209]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Tue, 12 Jul 2016 22:49:23 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Robert Varga <nite@hq.sk>, "draft-ietf-i2rs-yang-network-topo@tools.ietf.org" <draft-ietf-i2rs-yang-network-topo@tools.ietf.org>
Thread-Topic: [i2rs] network-type: container vs. identity?
Thread-Index: AdHYy2fqE/Tzjev7QKGinU6EIX1VyACVAuoAADMrWfA=
Date: Tue, 12 Jul 2016 14:49:23 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B7DEFF3AF@SZXEMA512-MBS.china.huawei.com>
References: <C636AF2FA540124E9B9ACB5A6BECCE6B7DEDFCE6@SZXEMA512-MBS.china.huawei.com> <5c0b2dee-fe0b-139d-1b1e-dc6936ff747d@hq.sk>
In-Reply-To: <5c0b2dee-fe0b-139d-1b1e-dc6936ff747d@hq.sk>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5785037A.01DC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.209, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 06a0e974932102a99bc5ff0763422386
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/-59WNhL24WQb1CzgmodP6jbqyZc>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] network-type: container vs. identity?
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 15:17:41 -0000

Hi, Robert, 

   Thank you for your clarification. Just make sure I get your point, let me try with a (real) example. 

   At the moment, we have the following relationship among different topology types ( using the diagram from https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-02 as base):

            +-----------------------------+
           |  +-----------------------+  |
           |  |    ietf-network |  |
           |  +----------^------------+  |
           |         |            |
           |  +-----------------------+  |
           |  | ietf-network-topology |  |-------< [ietf-te-topology]------<[ otn-topology] ( as an example)
           |  +----------+------------+  |
           +-------------^---------------+
                         |
                         |
             +-----------^-------------+
             | l3-unicast-igp-topology |
             +----+---------------+----+
                  ^               ^
                  |               |
                  |               |
         +--------^-----+      +-----^---------+
         | ospf-topology|    | isis-topology |
         +--------------+       +---------------+

So, this shows support of more than two levels of relationships and many branches. Is that what you mean by multiple traits and composition? Although I do not see an example using this identity for this, but I wonder if the following way of using identity is supported and can be used to cater your need? 

Identity network-types {
  Description "base type for network types";
}

Identity type-topology {
 Base "network-types";
}

Identity type-l3-unicast-igp {
 Base " type-topology ";
}

Identity type-ospf {
 Base "type-l3-unicast-igp";
}

I am cooking the codes up with my limited understanding of YANG, so I might be wrong. If so, please do let me know. 

Cheers,
Xian

-----Original Message-----
From: Robert Varga [mailto:nite@hq.sk] 
Sent: 2016年7月11日 18:54
To: Zhangxian (Xian); draft-ietf-i2rs-yang-network-topo@tools.ietf.org
Cc: i2rs@ietf.org
Subject: Re: [i2rs] network-type: container vs. identity?

On 07/08/2016 05:47 AM, Zhangxian (Xian) wrote:
> Hi, Authors,
> 
>  
> 
>    while using this model as a base to augment for technology-specific 
> topologies, I wonder why the leaf network-types is a container, 
> instead of being as a identity?
> 
>  
> 
> I remember I asked Alex offline before, but the response I got was 
> that the identity was also under consideration at that time. Given the 
> latest version (June 2016 version) still use container, I wonder if 
> the authors can explain why the alternative is discarded? Thank you.

The idea is to be able to have multiple traits, for example for composition.

Bye,
Robert