Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Xufeng Liu <[e-mail]>]

Hi Martin,

I know that this is a previously discussed solution, but I still have some issues with it:

1) In the case of the interfaces model, for each referenced interface-state, the operator needs to configure an interface object with the same interface name. However, in the case of the topology model, if we need to reference an underlay link-state, we will need to configure a topology (called network), a source node, a destination node, a source termination-point, a destination termination-point, which are five objects without including other consequent mandatory objects.

2) This approach stretches the definition of "system generated" non-configurable objects. The system generated objects mentioned in 1) are designed to be not configurable. Configuring them may result un-desirable consequences.

3) In general, this approach will not work if the referenced schema leaf is marked as "config false". In such a case, we cannot configure such a referenced leaf since it is not configurable.

Thanks,

- Xufeng

> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]]
> Sent: Thursday, February 2, 2017 2:33 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; draft-ietf-i2rs-yang-l3-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-
> topology-08: (with COMMENT)
> 
> Alexander Clemm <[e-mail]> wrote:
> > We are working this separately and will articulate the different
> > options and their respective issues.
> >
> > The fundamental issue is still the fact that you may have dependencies
> > in overlay topologies on underlay topologies that are discovered and
> > represent “state”, and that in fact your underlay may be either.
> >
> > RFC 7223, as far as I can tell, sidesteps this issue.  It does define
> > a type “interface-ref” with a path to reference a configured
> > interface, and it does define a type “interface-state-ref” to
> > reference an operationally present interface.  However,
> > interface-state-ref is used only in read-only objects, whereas (to put
> > the analogy) it is needed for configurable objects as well.  Likewise,
> > there are two types; really we need a union which would allow either
> > (or a leafref with alternate paths, which is not supported).  While
> > there are some analogies with a preprovisioning scenario, there are
> > also differences.
> 
> When people refer to the "pre-provisioning approach" in RFC 7223, it is not the
> "interface-ref" or "interface-state-ref" they refer to.
> 
> The pre-provisioning mechanism in RFC 7223 says that when the device
> initializes a detected interface, it will check the configuration to see if there is
> config available for an interface with the same name as the newly detected one.
> If so, that config is used.
> 
> I think the idea was to use something similar here.  E.g., allow a configured
> overlay to refer to a discovered underlay by name.  In YANG, this can be done
> with a node with the same type; or possibly with a leafref to the state data with
> "require-instance false".
> 
> This design allows an overlay to be configured for an existing detected underlay.
> Let's say the device reboots and starts to rebuild its topologies.  During some
> period of time, the configured overlay still exist in the config, but not in the state,
> since the underlay is not yet available.  Once it becomes instantiated in the state,
> the overlay is also instantiated in the state.  (This assumes that the system-
> generated topology names do not change).
> 
> 
> /martin
> 
> 
> 
> >
> > Anyway, Xufeng, Kent, Pavan and I are having offline discussions and
> > will come back with further elaboration on this.
> >
> > --- Alex
> >
> > From: i2rs [mailto:[e-mail]] On Behalf Of Alia Atlas
> > Sent: Wednesday, February 01, 2017 1:14 PM
> > To: Lou Berger <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> >
> > On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger
> > <[e-mail]<mailto:[e-mail]>> wrote:
> >
> >
> > On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote:
> > > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote:
> > >> Juergen,
> > >>
> > >>     What precludes treating such dependencies in the same way
> > >> per-provisioning is handled by RFC7223?
> > >>
> > > This is fine. But having direct dependencies, e.g., leafrefs from
> > > config true leafs to config false leafs, is not.
> > >
> > > /js
> > >
> >
> > Okay, then we're on the same page -- I think some may have missed the
> > possibility of handling references to dynamic topology information in
> > config using a 'pre-provisioning' approach.
> >
> > I would be happy to see Alex, Xufeng, Kent & Pavan articulate what
> > this would look like and how it would work for the base topology
> > model, so that the WG can consider all potentially viable options.
> > I'm not certain how it would function for the recursive nature and it
> > does presume the separate /config and /oper-state trees in the
> > data-model that were a concern (though certainly the current
> > recommended approach for YANG models).
> >
> > Regards,
> > Alia