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

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

Based on the discussions completing, I believe there to be rough consensus on the configuration of a VRF for a configured subscription being via a leafref to network-instances with vrf-support being an if-feature.  I.e.:
+--ro source-vrf?   ->  /ni:network-instances/network-instance/name {supports-vrf}?

Based on the planned time frame for network-instances.yang going to the IESG, I don't expect there to be any timing issues.  But if it does turn out that there is a delay in this draft, this issue many need to be revisited.

Eric

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