Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

I am fine with that change, but wanted to bring up one additional option that was also briefly mentioned in the room which strikes me as perhaps a bit more elegant.  That is the option to use augmentation.  In that case, source-vrf and the import statement would simply be omitted. Instead, a new module would be created (e.g. ietf-vrf-for-subscribed-notifications), which contains the import statement and two augments statements to augment the source-vrf into the existing module.

--- Alex

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Friday, November 17, 2017 10:46 AM
To: Eric Voit (evoit) <evoit@cisco.com>; netconf@ietf.org; Lou Berger <lberger@labn.net>
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

On 17/11/2017 18:17, Eric Voit (evoit) wrote:
I would like to continue the discussion on this topic from our session.   I think we came to agreement among the attendees.   Hopefully this thread can confirm, or refine as need.

First let’s look at Robert’s proposal below:
There are lots of good elements in Robert’s proposal below, but it isn’t up to our WG to determine the proper structure of the network-instance-model.   Authors of that model were in the room, and are aware that YANG model developers from outside would welcome a partitioning which decouples any linkages to schema-mount when all that is needed is to identify a VRF by name.

Looking at what we can control, discussed in the room was the following change to subscribed-notifications:

1.       import “ietf-network-instance”

2.       create if-feature “VRF”.

3.       apply feature “VRF” to object “source-VRF”

4.       Leafref to “source-VRF” to validate against the network-instance model’s /network-instances/network-instance/name.

This is the current proposal.  Are there are concerns/objections/refinements?

No concerns, but perhaps one trivial refinement.

I had mistakenly thought that a device would either support VRFs for all protocols or none, hence my suggestion to have a single "VRF" feature, which would naturally be defined by the network-instances model.

In the discussions that I had with Lou, some of them at the mic, some afterwards, Lou clarified that it quite plausible that VRFs may only be supported by some protocols on a device and not all, and hence the solution of having a "VRF" feature per protocol seems like the right solution.

I think that I would call the feature "supports-vrf" rather than "vrf".

Thanks,
Rob

Eric

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, November 14, 2017 10:23 PM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <rwilton@cisco.com><mailto:rwilton@cisco.com>; netconf@ietf.org<mailto:netconf@ietf.org>; Lou Berger <lberger@labn.net><mailto:lberger@labn.net>
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

Agree it is a generic problem.

I would defer to Lou and the other authors of draft-ietf-rtgwg-ni-model as this would be a fairly significant change.

Eric

From: Robert Wilton, November 14, 2017 7:58 PM

Hi Eric, Lou,

This seems to be a generic problem.

Could the VRF leafref name dependency issue be solved with an if-feature statement?.

I.e.could the network instance draft define a separate YANG module (with no dependencies) that defines a "VRF" feature.

All the VRF references (ideally if all IETF YANG modules that may optionally depend on VRFs) could be leaf-refs to /network-instances/network-instance/name but predicated with an if-feature "ni:vrf".

Hence if a device doesn't support VRFs, then it doesn't implement the "vrf" feature, so it doesn't have to implement the full network instances module, or schema mount.

Thanks,
Rob

On 15/11/2017 08:45, Eric Voit (evoit) wrote:

In the WG session tomorrow, I am hoping to get “hum feedback” on:

draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/5

The two choices exposed during the two week review for how to represent Source VRF of configured subscription were:

(1) Leafref to “ietf-network-instance”  /network-instances/network-instance/name

·         Creates dependency on schema mount for subscriptions.

·         Source VRF is an optional capability, but publishers that don’t care about VRFs must still import.  (Note: could also augment the leafref in another model, but that adds another layer of complexity)

·         establishes model dependency to draft-ietf-rtgwg-ni-model

(2) Use a string which would be populated with exact same name as would be in the leafref of (1)

·         Possible to name VRF which doesn’t exist

The current draft does (2).

Thanks,

Eric

_______________________________________________

Netconf mailing list

Netconf@ietf.org<mailto:Netconf@ietf.org>

https://www.ietf.org/mailman/listinfo/netconf

.