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

[Martin Bjorklund <[e-mail]>]

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