Re: [Supa] Comments on draft-contreras-supa-yang-network-topo-00

Martin Bjorklund <mbj@tail-f.com> Wed, 01 October 2014 12:31 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B571A0330 for <supa@ietfa.amsl.com>; Wed, 1 Oct 2014 05:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level:
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 jZPYVP0pdQUR for <supa@ietfa.amsl.com>; Wed, 1 Oct 2014 05:31:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 63E0E1A0296 for <supa@ietf.org>; Wed, 1 Oct 2014 05:31:11 -0700 (PDT)
Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 62E8B1280BD3; Wed, 1 Oct 2014 14:31:10 +0200 (CEST)
Date: Wed, 01 Oct 2014 14:31:09 +0200
Message-Id: <20141001.143109.1986696969232543149.mbj@tail-f.com>
To: Tina.Tsou.Zouting@huawei.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A8185A90E5@szxeml557-mbs.china.huawei.com>
References: <C0E0A32284495243BDE0AC8A066631A8185A6B80@szxeml557-mbs.china.huawei.com> <C0E0A32284495243BDE0AC8A066631A8185A90E5@szxeml557-mbs.china.huawei.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/M3hCV7KTIHMaVtcz1AwMU7UJukc
X-Mailman-Approved-At: Wed, 01 Oct 2014 17:47:12 -0700
Cc: luismiguel.contrerasmurillo@telefonica.com, andrew.qu@mediatek.com, supa@ietf.org
Subject: Re: [Supa] Comments on draft-contreras-supa-yang-network-topo-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Oct 2014 12:31:14 -0000

Hi,

Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:
> Dear Martin,
> 
> We discussed off-line how the supa topology draft is related to the
> i2rs topology draft, I feel it is worthy to bring it to the list for
> broader audience.
> 
> This draft
> http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/

I was also thinking about this draft:
http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

... which I now realize was posted as not as i2rs, but netmod.


/martin



> also focused on network topology information model which is also
> within the scope of SUPA topology model. However, besides the common
> interests at topology model, there are still significant differences
> between the two.
> 
> 1.  The I2RS topology model is based on a service topology which is
> closely related to certain service. And the service topology can be
> dedicated to one tenant or multiple tenants. For SUPA, different
> layers have different views or representations of the same network
> topology. Multiple users may not "share" the same topology but use
> their own topology at their own layer.
> 
> 
> 
> 2.  The I2RS topology model use service topologies which should be
> independent from network topology and therefore should not map onto
> other underlay topologies. The SUPA topology model is a unified
> topology model to support service at all levels. Each level can have
> its own representation of the topology.
> 
> 
> 3.  There is no YANG based topology model in this I2RS draft yet. SUPA
> has a well defined YANG data model to describe the topology.
> 
> All in all, the two drafts have something in common and the basic
> principals are very close. IMO, service topology can be one use case
> for SUPA topology model to be used in BGP, OSPF and so on.
> 
> 
> Thank you,
> Tina
> 
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU
> Sent: Sunday, September 28, 2014 12:30 PM
> To: LUIS MIGUEL CONTRERAS MURILLO; andrew.qu@mediatek.com
> Cc: supa@ietf.org
> Subject: [Supa] Comments on draft-contreras-supa-yang-network-topo-00
> 
> Dear Luis, Andrew et al,
> 
> Thank you for writing such a concrete model.
> 
> I read
> draft-contreras-supa-yang-network-topo-00<http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/>. It
> is well written. Below are some comments.
> 
> The basic idea of this draft is very good, and I can understand what
> the author tries to say. However still, more clarification is needed
> especially for some definitions.
> 
> 1.  In section 4.2, there are "virtual node" and "container node",
> what is difference between these two kinds of nodes? For the virtual
> node, it is more understandable that it is the virtualization of the
> physical node or nodes. But for the container node, it can be a group
> of nodes or only one node. What is the necessity to define such a
> container node, is it domain specific or a general idea for all the
> use cases?
> 
> 
> 
> 2.  Would you elaborate one use case for the container node? In order
> to demonstrate the insufficiency of virtual node to cover the
> application or use cases, show one use case that the container node
> idea is necessary.
> 
> 
> 3.  In section 4.2, there is also some external links or nodes
> definition, what is the purpose for that? Are they external for the
> user or the up level controller?
> 
> 
> 4.       In first figure of section 4
>                   +-------------------------+
>                   |                         |
>                   |       topology          |
>                   |                         |
>                   +-+-+----+---------+--+-+-+
>                     | |    |         |  | |
>                     | |    |         |  | |
>                     | |    |         |  | |
>                     | |    |         |  | |
>       +------------+ |    |         |  | |
>        |              |    |         |  | +------------------+
>        |        +-----+    |         |  +--------+           |
>        |        |          |         +-+         |           |
>        |        |          |           |         |           |
>     +--+---+ +--+---+ +----+------++---+---+ +---+---+ +-----+-----+
>     |link  | |node  | |termination||extLink| |extNode| |extTerminat|
>     +------+ +------+ |Point      |+-------+ +-------+ |ionPoint   |
>                       +-----------+                    +-----------+
> 
> How can the unified topology be mapped into different applications or
> users? I guess you need to map this topology, if this is the only one
> topology, to different applications in order to make it work.
> 
> 
> Thank you,
> Tina
>