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

["Eric Voit (evoit)" <[e-mail]>]

Hi Lou,

> From: Lou Berger, November 21, 2017 9:37 AM
> 
> Eric,
> 
> See below
> 
> On 11/21/2017 08:06 AM, Eric Voit (evoit) wrote:
> > 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.
> 
> 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?

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)
> 
> 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 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.
> >
> 
> So this sounds like the provider config policy, right?

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

> >
> >> 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.
> 
> the augmentation to interfaces is called bind-ni-name, as long as you
> reference it or ni-name all is good.

Excellent.   Model now uses:

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

Eric

 
> Lou
> >
> > Eric
> >
> >> 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.
> >>>
> >>> 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:[e-mail]]
> >>>> *Sent:* Monday, November 20, 2017 11:39 AM
> >>>> *To:* Alexander Clemm <[e-mail]
> >>>> <mailto:[e-mail]>>; Robert Wilton -X (rwilton -
> >>>> ENSOFT LIMITED at Cisco) <[e-mail]
> >>>> <mailto:[e-mail]>>; [e-mail]
> >>>> <mailto:[e-mail]>; Lou Berger <[e-mail]
> >>>> <mailto:[e-mail]>>
> >>>> *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:[e-mail]]
> >>>> *Sent:* Monday, November 20, 2017 2:27 PM
> >>>> *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> >>>> <[e-mail] <mailto:[e-mail]>>; Eric Voit (evoit)
> >>>> <[e-mail] <mailto:[e-mail]>>; [e-mail]
> >>>> <mailto:[e-mail]>; Lou Berger <[e-mail]
> >>>> <mailto:[e-mail]>>
> >>>> *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:[e-mail]] *On Behalf Of
> >>>> *Robert Wilton
> >>>> *Sent:* Friday, November 17, 2017 10:46 AM
> >>>> *To:* Eric Voit (evoit) <[e-mail] <mailto:[e-mail]>>;
> >>>> [e-mail] <mailto:[e-mail]>; Lou Berger
> >>>> <[e-mail] <mailto:[e-mail]>>
> >>>> *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:[e-mail]] *On Behalf Of
> >>>>     *Eric Voit (evoit)
> >>>>     *Sent:* Tuesday, November 14, 2017 10:23 PM
> >>>>     *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> >>>>     <[e-mail]> <mailto:[e-mail]>;
> [e-mail]
> >>>>     <mailto:[e-mail]>; Lou Berger <[e-mail]>
> >>>>     <mailto:[e-mail]>
> >>>>     *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
> >>>>
> >>>>         [e-mail] <mailto:[e-mail]>
> >>>>
> >>>>         https://www.ietf.org/mailman/listinfo/netconf
> >>>>
> >>>>
> >>>>
> >>>>     .
> >>>>
> >>>>
> >>>>
> >>>
> >