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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Nov 2017 00:45:47 +0000

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 15 Nov 2017 08:58:14 +0800

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:
>
> 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
>
> ·Possible to name VRF which doesn’t exist
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Nov 2017 03:22:37 +0000

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,

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

Thanks,

Eric

Netconf mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 17 Nov 2017 18:17:21 +0000

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?

Eric

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

Eric

Hi Eric, Lou,

Thanks,
Rob

Thanks,

Eric

Netconf mailing list

---

From: Robert Wilton <[email-masked]>
Date: Fri, 17 Nov 2017 18:45:48 +0000

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

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:[email-masked]] *On Behalf Of *Eric 
> Voit (evoit)
> *Sent:* Tuesday, November 14, 2017 10:23 PM
> *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
> <[email-masked]>; [email-masked]; Lou Berger <[email-masked]>
> *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF of 
> configured subscription?
>
> 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,
>
> I.e.could the network instance draft define a separate YANG module 
> (with no dependencies) that defines a "VRF" feature.
>
>     ·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)
>
>     [email-masked] <mailto:[email-masked]>
>
> .

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 20 Nov 2017 13:34:07 +0000

From: Robert Wilton, November 17, 2017 1:46 PM

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.

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.

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.

<Eric> “supports-vrf” is fine with me.  Also as we only have one transport per subscription, any error checking on configuration should be straightforward.

Eric

Thanks,
Rob

Eric

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

Eric

Hi Eric, Lou,

Thanks,
Rob

(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

·        Possible to name VRF which doesn’t exist

Thanks,

Eric

Netconf mailing list

.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Nov 2017 14:43:05 +0100

On Mon, Nov 20, 2017 at 01:34:07PM +0000, Eric Voit (evoit) wrote:

[...]

> <Eric> “supports-vrf” is fine with me.  Also as we only have one transport per subscription, any error checking on configuration should be straightforward.

Since this same question (how to support VRFs) has come up in other
contexts, it would really be good if it would be documented, say in
the network instances draft, how other protocol models should refer to
VRFs - ideally with the rationale behind it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 20 Nov 2017 14:41:12 +0000

> From: Juergen Schoenwaelder, November 20, 2017 8:43 AM
> 
> > <Eric> “supports-vrf” is fine with me.  Also as we only have one transport
> per subscription, any error checking on configuration should be
> straightforward.
> >
> 
> contexts, it would really be good if it would be documented, say in the
> network instances draft, how other protocol models should refer to VRFs -
> ideally with the rationale behind it.

I agree that it would be helpful to include supporting context within the network instances draft.  Some elements worth covering:

(a) a "supports-vrf" if-feature maintained within network-instances which is available to any model wanting to refer to a VRF.

(b) Examples of constraint checking to see if a /network-instances/network-instance/name is only of root type:  vrf-root or vv-root.  (I.e., don't let someone configure an L2VPN via a Leafref)

Eric

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 20 Nov 2017 19:26:51 +0000

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:[email-masked]] On Behalf Of Robert Wilton
Sent: Friday, November 17, 2017 10:46 AM
To: Eric Voit (evoit) <[email-masked]>; [email-masked]; Lou Berger <[email-masked]>
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

Thanks,
Rob

Eric

Eric

Hi Eric, Lou,

Thanks,
Rob

Thanks,

Eric

Netconf mailing list

.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 20 Nov 2017 19:39:02 +0000

I agree this is more elegant if we look just at subscribed-notifications.   However extrapolating this means that we have a duplicate YANG module every time we have a VRF.   And in our case when we augment yang-push, which model do we start from?

Eric

From: Alexander Clemm [mailto:[email-masked]]
Sent: Monday, November 20, 2017 2:27 PM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]>; Eric Voit (evoit) <[email-masked]>; [email-masked]; Lou Berger <[email-masked]>
Subject: RE: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Friday, November 17, 2017 10:46 AM
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

Thanks,
Rob

Eric

Eric

Hi Eric, Lou,

Thanks,
Rob

Thanks,

Eric

Netconf mailing list

.

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 20 Nov 2017 19:46:01 +0000

Hi Eric,

I agree that proliferation of modules is a concern, and certainly we would not want to run into combinatorial explosions.  However, I don’t think this would be the case here - we would not need to augment VRF into yang-push also (or yang-push into VRF).  Instead, both yang-push and vrf-for-notifications would be augmenting subscribed-notifications in parallel.

--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Monday, November 20, 2017 11:39 AM
To: Alexander Clemm <[email-masked]>; Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]>; [email-masked]; Lou Berger <[email-masked]>
Subject: RE: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

Eric

From: Alexander Clemm [mailto:[email-masked]]
Sent: Monday, November 20, 2017 2:27 PM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]<mailto:[email-masked]>>; Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

--- Alex

Thanks,
Rob

Eric

Eric

Hi Eric, Lou,

Thanks,
Rob

Thanks,

Eric

Netconf mailing list

.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 20 Nov 2017 19:54:26 +0000

From: Alexander Clemm, November 20, 2017 2:46 PM

Hi Eric,

<Eric>  Yes, you are right, with this approach we would end with three models rather than four.  But two models is already a lot.   And we still set precedence that we end with a new VRF specific model every time any YANG model needs a VRF.
Eric

--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Monday, November 20, 2017 11:39 AM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?

Eric

--- Alex

Thanks,
Rob

Eric

Eric

Hi Eric, Lou,

Thanks,
Rob

Thanks,

Eric

Netconf mailing list

.

---

From: Robert Wilton <[email-masked]>
Date: Tue, 21 Nov 2017 09:56:14 +0000

I think that using a feature is better here.  Defining a separate module 
for just one leaf seems somewhat like overkill.

I'm not sure that any compile time dependency on network instances, and 
hence schema mount, is really an issue; the more important one to avoid 
is the run time dependency on network instances and schema mount, and 
both solutions achieve this.

But I also agree with Juergen's comment that we should be consistent, 
and the same approach should be used for other protocols with 
conditional dependencies on network instances as well.

Thanks,
Rob

On 20/11/2017 19:54, Eric Voit (evoit) wrote:
>
> *From:*Alexander Clemm, November 20, 2017 2:46 PM
>
> Hi Eric,
>
> I agree that proliferation of modules is a concern, and certainly we 
> would not want to run into combinatorial explosions. However, I don’t 
> think this would be the case here - we would not need to augment VRF 
> into yang-push also (or yang-push into VRF).  Instead, both yang-push 
> and vrf-for-notifications would be augmenting subscribed-notifications 
> in parallel.
>
> <Eric>  Yes, you are right, with this approach we would end with three 
> models rather than four.  But two models is already a lot.   And we 
> still set precedence that we end with a new VRF specific model every 
> time any YANG model needs a VRF.
>
> Eric
>
> --- Alex
>
> *From:*Eric Voit (evoit) [mailto:[email-masked]]
> *Sent:* Monday, November 20, 2017 11:39 AM
> *To:* Alexander Clemm <[email-masked] 
> <mailto:[email-masked]>>; Robert Wilton -X (rwilton - 
> ENSOFT LIMITED at Cisco) <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Lou Berger <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of 
> configured subscription?
>
> I agree this is more elegant if we look just at 
> subscribed-notifications.   However extrapolating this means that we 
> have a duplicate YANG module every time we have a VRF.   And in our 
> case when we augment yang-push, which model do we start from?
>
> Eric
>
> *From:*Alexander Clemm [mailto:[email-masked]]
> *Sent:* Monday, November 20, 2017 2:27 PM
> <[email-masked] <mailto:[email-masked]>>; Eric Voit (evoit) 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Lou Berger <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* 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:[email-masked]] *On Behalf Of *Robert 
> Wilton
> *Sent:* Friday, November 17, 2017 10:46 AM
> *To:* Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>; Lou Berger 
> <[email-masked] <mailto:[email-masked]>>
>     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.
>
> 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.
>
> 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 
>     *From:*Netconf [mailto:[email-masked]] *On Behalf Of
>     *Eric Voit (evoit)
>     <[email-masked]> <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Lou Berger <[email-masked]>
>     <mailto:[email-masked]>
>     *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF
>     of configured subscription?
>
>     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
>
>         ·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)
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 Nov 2017 07:16:15 -0500

Taking a step back: what is the purpose of having source-vrf in
draft-ietf-netconf-subscribed-notifications?

>From the configuration side, the model seems to allow the configuration
of an IP address for  notification-message-origin that doesn't match any
configured interface.  Does this really make sense?  Why not just limit
configuration to if:interface-ref?  Doing this eliminates the whole VRF
discussion for this model (of course, I'm not saying the discussion
won't happen in other contexts). 

What am I missing?

Also if you do keep 'source-vrf' I think 'source-ni-name' is more
consistent with draft-ietf-rtgwg-ni-model augmentations of if:interface.

Lou

On 11/21/2017 4:56 AM, Robert Wilton wrote:
>
> I think that using a feature is better here.  Defining a separate
> module for just one leaf seems somewhat like overkill.
>
> I'm not sure that any compile time dependency on network instances,
> and hence schema mount, is really an issue; the more important one to
> avoid is the run time dependency on network instances and schema
> mount, and both solutions achieve this.
>
>> would not want to run into combinatorial explosions.  However, I
>> don’t think this would be the case here - we would not need to
>> augment VRF into yang-push also (or yang-push into VRF).  Instead,
>> both yang-push and vrf-for-notifications would be augmenting
>> subscribed-notifications in parallel. 
>>
>>  
>>
>> <Eric>  Yes, you are right, with this approach we would end with
>> three models rather than four.  But two models is already a lot. 
>>  And we still set precedence that we end with a new VRF specific
>> model every time any YANG model needs a VRF. 
>>
>> Eric
>>
>>  
>>
>> --- Alex
>>
>>  
>>
>> 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.
>> *Robert Wilton
>>     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
>>     4.      Leafref to “source-VRF” to validate against the
>>     network-instance model’s /network-instances/network-instance/name. 
>>
>>      
>>
>>     I.e.could the network instance draft define a separate YANG
>>     module (with no dependencies) that defines a "VRF" feature.
>>
>>         ·        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)
>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 21 Nov 2017 13:06:13 +0000

Hi Lou,

> From: Lou Berger, November 21, 2017 7:16 AM
> 
> Taking a step back: what is the purpose of having source-vrf in draft-ietf-
> netconf-subscribed-notifications?

There are many uses for this, and not having it is already being seen as a production problem in two separate telemetry environments:
(1) Being able to push telemetry traffic to one or more collection VRFs which are not exposed in the global routing table.
(2) Being able to send routing and switching info relevant to a specific customer VRFs on that customer's VRF.  (I.e., provide traffic counters to a collection IP address/domain for that VRF)
 
> From the configuration side, the model seems to allow the configuration of
> an IP address for  notification-message-origin that doesn't match any
> configuration to if:interface-ref? 

The person doing the configuration need have no understanding of the interfaces on the router.  In addition, if the ni-name is the same across routers, the same ni-name can be used across the domain without knowledge of such device specifics.

> Doing this eliminates the whole VRF
> discussion for this model (of course, I'm not saying the discussion won't
> happen in other contexts).
> 
> What am I missing?

This type of configuration is really aimed at a level higher than someone who needs care about topology issues.  They just want something out of the network cloud.   It is quite possible to configure the same subscription info to all devices in a domain without any per-device deviations at all.  (I.e., same configured subscription-id, same filter, same VRF, same period, ...)

> Also if you do keep 'source-vrf' I think 'source-ni-name' is more consistent
> with draft-ietf-rtgwg-ni-model augmentations of if:interface.

"Ni-name" is more generic because it supports more types of technologies than required at this time.   As no customer is talking about things beyond VRF, installing the more generic name would be an added layer of complexity.

Eric
 
> >>     network-instance model’s
> >> /network-instances/network-instance/name.
> >>
> >>
> >>

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 Nov 2017 09:37:04 -0500

Eric,

See below

> (1) Being able to push telemetry traffic to one or more collection VRFs which are not exposed in the global routing table.

By "collection VRFs" you mean that the configured receivers are only
reachable within the context of a VRF/NI, right?  If not, I don't think
I follow. I this case, the SN configuration is still server-wide and not
scoped per NI/VRF, right?

> (2) Being able to send routing and switching info relevant to a specific customer VRFs on that customer's VRF.  (I.e., provide traffic counters to a collection IP address/domain for that VRF)

Now we're getting somewhere.  So you also have a use case where SNs are
VRF-specific, right? Does config happen inside the context of the VRF or
the core instance?  Is there a separate logical management instance for
the VRF?

> The person doing the configuration need have no understanding of the interfaces on the router.  In addition, if the ni-name is the same across routers, the same ni-name can be used across the domai…

So this sounds like the provider config policy, right?

> This type of configuration is really aimed at a level higher than someone who needs care about topology issues. 

What topology issues?

> They just want something out of the network cloud.   It is quite possible to configure the same subscription info to all devices in a domain without any per-device deviations at all.  (I.e., same configured subscription-id, same filter, same VRF, same period, ...)

So this case would configure vrf but not source IP, right?  Is there a
use case for source ip?

> "Ni-name" is more generic because it supports more types of technologies than required at this time.   As no customer is talking about things beyond VRF, installing the more generic name would be a…

the augmentation to interfaces is called bind-ni-name, as long as you
reference it or ni-name all is good.

Lou

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 21 Nov 2017 16:30:25 +0000

Hi Lou,

> From: Lou Berger, November 21, 2017 9:37 AM
> 
> Eric,
> 
> See below
> 
> >> draft-ietf- netconf-subscribed-notifications?
> >
> > There are many uses for this, and not having it is already being seen as a
> production problem in two separate telemetry environments:
> > (1) Being able to push telemetry traffic to one or more collection VRFs
> which are not exposed in the global routing table.
> 
> reachable within the context of a VRF/NI, right?  If not, I don't think I follow.
> I this case, the SN configuration is still server-wide and not scoped per
> NI/VRF, right?

Yes to both.   Here we have a Telemetry Server gathering pretty much anything about a set of network devices, but sending the telemetry traffic out on a dedicated management VRF.
 
> > (2) Being able to send routing and switching info relevant to a
> > specific customer VRFs on that customer's VRF.  (I.e., provide traffic
> > counters to a collection IP address/domain for that VRF)
> 
> VRF-specific, right? Does config happen inside the context of the VRF or the
> core instance?  Is there a separate logical management instance for the
> VRF?

The configuration of the subscription is in the core instance.   I have not yet heard any requirements for configured subscriptions under a VRF instance.

> >
> >> From the configuration side, the model seems to allow the
> >> configuration of an IP address for  notification-message-origin that
> >> doesn't match any configured interface.  Does this really make sense?
> >> Why not just limit configuration to if:interface-ref?
> >
> > The person doing the configuration need have no understanding of the
> interfaces on the router.  In addition, if the ni-name is the same across
> routers, the same ni-name can be used across the domain without
> knowledge of such device specifics.
> >
> 

Depending on what you mean by that, I believe the answer is Yes.  The configuration policy is to send to an IP address on this VRF.   And for management simplification/security, we are not allowing a single subscription to have independent receivers located in different VRFs.
 
> who needs care about topology issues.

Topology issues was short-hand for networking specifics.  Let's say the subscription is just for CPU Temperature, or for configured keys, or for running processes, etc...   In this case, there is no need to care about interfaces, link status, adjacencies, etc.

> > They just want something out of the network cloud.   It is quite possible
> to configure the same subscription info to all devices in a domain without
> any per-device deviations at all.  (I.e., same configured subscription-id, same
> filter, same VRF, same period, ...)
> 
> So this case would configure vrf but not source IP, right?  Is there a use case
> for source ip?

Yes.  At least one large data center customer has wanted to use source-IP to allow differentiation of content on the WAN.   This is presumably for QoS purposes.   Personally I would rather use other QoS constructs as there is less change for miss-configuration.  But signaling via source address is a valid way to do network design which relies less on the capabilities of specific vendors.

> > "Ni-name" is more generic because it supports more types of technologies
> than required at this time.   As no customer is talking about things beyond
> VRF, installing the more generic name would be an added layer of
> complexity.
> 

Excellent.   Model now uses:

          type leafref {
            path "/ni:network-instances/ni:network-instance/ni:name";
          }

Eric

> >>> and hence schema mount, is really an issue; the more important one
> >>> to avoid is the run time dependency on network instances and schema
> >>> But I also agree with Juergen's comment that we should be
> >>> consistent, and the same approach should be used for other protocols
> >>> with conditional dependencies on network instances as well.
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>>> I agree that proliferation of modules is a concern, and certainly
> >>>> we would not want to run into combinatorial explosions.  However, I
> >>>> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF
> >>>> subscribed-notifications.   However extrapolating this means that
> >>>> we have a duplicate YANG module every time we have a VRF.   And in
> >>>> our case when we augment yang-push, which model do we start
> from?
> >>>>
> >>>>
> >>>>
> >>>> Eric
> >>>>
> >>>>
> >>>>
> >>>> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF
> >>>> statement and two augments statements to augment the source-vrf
> >>>> into the existing module.
> >>>>
> >>>>
> >>>>
> >>>> --- Alex
> >>>>
> >>>>
> >>>>
> >>>> I had mistakenly thought that a device would either support VRFs
> >>>> for all protocols or none, hence my suggestion to have a single "VRF"
> >>>> 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.
> >>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 Nov 2017 14:08:05 -0500

>             path "/ni:network-instances/ni:network-instance/ni:name";

Okay then.  You probably want to mention that wen ni-name is set the ip
address must be assigned to an interfaces with the matching bind-ni-name.

Lou