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

["Liubing (Leo)" <[e-mail]>]

Hi Andy,

Thanks for your comments. Please see replies inline.

From: Andy Bierman [mailto:[e-mail]]
Sent: Thursday, July 03, 2014 2:36 AM
To: Liubing (Leo)
Cc: Netconf; [e-mail]<mailto:[e-mail]>; Zhengguangying; Yangang
Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt

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 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?

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?

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




On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf