Re: [netmod] [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt

"Liubing (Leo)" <leo.liubing@huawei.com> Mon, 07 July 2014 07:45 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBFE1B2793; Mon, 7 Jul 2014 00:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.816
X-Spam-Level:
X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 9JLgVWlI4er0; Mon, 7 Jul 2014 00:45:41 -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 C48D51A8BB3; Mon, 7 Jul 2014 00:45:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR87830; Mon, 07 Jul 2014 07:45:38 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 08:45:00 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 15:44:48 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt
Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrZuMlwyAgAEfORCAAdZYgIAEmsjA
Date: Mon, 07 Jul 2014 07:44:48 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1@nkgeml506-mbx.china.huawei.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> <CABCOCHQx5_=yVG4Kxzw_pD1EJ7SYz+c6gNMRBywQm1-ArVeBpw@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> <CABCOCHQyRcw-HCKc0okOGjFK1FTUEWC2+NW3=GrC9q=vBTvV1Q@mail.gmail.com>
In-Reply-To: <CABCOCHQyRcw-HCKc0okOGjFK1FTUEWC2+NW3=GrC9q=vBTvV1Q@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.132]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iNuJ6DX98tLw7Go_ATdDWwwP3q8
Cc: Zhengguangying <zhengguangying@huawei.com>, Netconf <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Subject: Re: [netmod] [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 07:45:45 -0000

Hi Andy,

Hi,

I read your draft and it I can see use-cases for a context-ID.
I prefer to think of named virtual hosts in Apache2, rather than
SNMP contexts.
[Bing] May I ask the specific reasons that you don't prefer SNMP context?
We also had some concern that since context doesn't specify the content, it may have problem on standardization. But we just thought it could be a familiar concept to the network management people.


I think SNMP Context has been misused.  IMO it is better to have an
explicit index in a data structure schema, rather than add an INDEX on the side
using the context-ID.
[Bing] I see your point. An explicit data structure schema might be better for standardization. We'll consider your approach at the solution discussion stage.

I don't think your solution is fully specified, but it is a good start.
[Bing] Yes, the solution part of the document is mostly a hint for further discussion. At this stage, we'd like to hear more opinions on the problem/gap analysis part.

I think the following solution could easily work, which is just a
refinement of your solution in sec. 4.1.

 1) define a 'server-id' XML attribute
 2) define a NETCONF 'virtual-server' capability indicating the server supports the 'server-id' attribute
 3) the server is already required to accept all attributes in the <rpc> start tag and return
     them in the <rpc-reply> start tag. (So sending the server-id attribute is safe in all cases).
 4) If the server supports the capability, then it must check for the server-id attribute in each <rpc>
     and use the correct virtual server or else return an error if it is an unknown server-id.

[Bing] We thought your proposal is also a good solution.
If we go this way, then there might be a problem that is a single "server-id" sufficient to identify the targeted instance? Since LS and VS might co-exist in one device, thus one LS might contain multiple VSes. Then there comes a hierarchy of the server-id. Maybe we need a comprehensive structure to well express the hierarchical id?



But you had a single context-id.  How is that any different?
[Bing] Context doesn't specify the content, so it could be coded to implicitly express the hierarchical id.
Nevertheless, I was not arguing context is better on this issue. I was just thinking, if we follow the way of explicitly specifying the "server-id" attribute, then maybe the attribute itself needs to support hierarchy express of the targeted instance.

Named virtual hosts are useful in Apache2 because allocating an IP address to
each WEB server is not always possible.  Each virtual server is its own instance and
content is independent across virtual servers.  Each HTTP request is routed from the
real server to the correct virtual server, based on the hostname in the URL.

A hierarchy would have to be based on content, and in that case,
a data modeling solution is needed, not nested virtual servers.
[Bing] This is the HTTP Server case.  Considering a complicated router, which is divided into several Logical Systems, and each Logical System contain several Virtual Systems doing different routing tasks. Then a single hostname is not sufficient enough to represent the VS, there needs to be a hierarchical expression such as "LS_name.VS_name".



I don't really understand Gap-2 and Gap-3 so I am not addressing that.  It looks like
it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01).
IMO that is a completely different problem -- configuration of a mid-level-manager.

[Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Let me explain them with some examples.

Req-2/Gap-2: a YANG model itself needs to support multiple instances, for example:

-        the routing model (draft-ietf-netmod-routing-cfg) clearly defines "routing instance" to support VRF instances

-        the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af [vrf-name afi safi]" to support multiple OSPF engines (instances).
Say, if an existing model doesn't support multiple instances, and in the future for some reason we need to manage them as multiple instances. How do we extend the existing model?

Republish the model with the new key.
[Bing] This is certainly an approach.
We including this as a gap is to see whether there could be a more scalable solution, such as Section 4.2 "Common Service Container".

Best regards,
Bing

Req-3a/Gap-3a: Configuring a service under another
E.g., the above mentioned OSPF module is defined under the routing instance (VRF) defined in routing model through augment:
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
         + "rt:routing-protocol" {
     list ospf-router {
     ...
Then, we could configure the OSPF under the routing data model, there is no problem/gap with this example. However, consider another example: if we're going to write a new model, say, L3VPN, can we just re-use the whole routing model also through augment? (Just to confirm, I'm not sure whether YANG is able to do this or not. If YANG is already be able to do it, then maybe we should remove the gap.)

Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple instances
E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name afi safi]" to support multiple OSPF engines (instances), it means the OSPF model be aware of the VRF multiple instances, and there is an implication that the OSPF instance is binding to the VRF instance. This kind of awareness/binding might face the scalability issue. Say, if something like VRF comes out in the future, how does current OSPF model to support that new kind of instance?

For "YANG mount" draft, my personal understanding is that it is a container to collect different modules in other location together in one place. While the above gaps are more regarding to relationships between different models. I think they have different scopes.

Best regards,
Bing



Andy



On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) <leo.liubing@huawei.com<mailto:leo.liubing@huawei.com>> wrote:
Hi all in Netconf & Netmod,

In last Netconf meeting in London, my colleague Guangying Zheng raised a question at the mike about how to distinguish multiple VRFs when using NETCONF to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue. The draft analyzes the management requirements for multiple instances like VRF, and pointed out some gaps in current NETCONF protocol and YANG models. At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF repository.

Name:           draft-liu-netconf-multi-instances
Revision:       00
Title:          Multi-Instances Configuration Issue in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring
   multiple instances including configuring multiple network element
   instances and multiple service instances. The main problem is how to
   configure the multiple instances in one NETCONF channel.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Netconf mailing list
Netconf@ietf.org<mailto:Netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf