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

[Andy Bierman <[e-mail]>]

On Fri, Jul 4, 2014 at 5:43 AM, Liubing (Leo) <[e-mail]>
wrote:

>  Hi Andy,
>
>
>
> Thanks for your comments. Please see replies inline.
>
>
>
> *From:* Andy Bierman [mailto:[e-mail] <[e-mail]>]
> *Sent:* Thursday, July 03, 2014 2:36 AM
> *To:* Liubing (Leo)
> *Cc:* Netconf; [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 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.



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

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.





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


>
>
> 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) <[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]]
> 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.
>
> The IETF Secretariat
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>