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

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 2 Jul 2014 09:51:26 +0000

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: [email-masked] [mailto:[email-masked]] 
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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Jul 2014 11:35:45 -0700

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.

I don't think your solution is fully specified, but it is a good start.
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.

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.

Andy

On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) <[email-masked]>
wrote:

> 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.
> 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.
>
> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 4 Jul 2014 12:43:37 +0000

Hi Andy,

Thanks for your comments. Please see replies inline.

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, July 03, 2014 2:36 AM
To: Liubing (Leo)
Cc: Netconf; [email-masked]<mailto:[email-masked]>; 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.

 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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all in Netconf & Netmod,

Best regards,
Bing

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
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

Abstract:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Jul 2014 08:47:11 -0700

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

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

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

> E.g., the above mentioned OSPF module is defined under the routing
> instance (VRF) defined in routing model through augment:
>
> 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.)
>
>
>
> 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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 7 Jul 2014 07:44:48 +0000

Hi Andy,

Hi,

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.

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

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

Best regards,
Bing

Andy

Best regards,
Bing

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
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

Abstract:

The IETF Secretariat