Hi Martin,
> -----Original Message-----
> From: Martin Bjorklund [mailto:[email protected]]
> Sent: Thursday, February 2, 2017 11:18 AM
> To: Xufeng Liu <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-
> topology-08: (with COMMENT)
>
> Hi,
>
> Xufeng Liu <[email protected]> wrote:
> > 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.
>
> You don't have to configure a "dummy" object if you are not using leafrefs to
> config. And the number of nodes that you need for unique identification
> should
> be totally independent.
[Xufeng] We have to do them in this case, because a link connects two
termination-points, with each of them are in a node, which can only exists
within the context of a topology. Without defining these objects, I cannot
configure a valid link.
>
> > 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.
>
> See above.
[Xufeng] We don't want to configure a node or link just because we need to
reference it. Configuring a node means that the system will need to perform a
series of tasks and may change the node to have different behaviors from
previous "system generated" non-configurable node.
>
> > 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.
>
> I don't understand this comment.
[Xufeng] Assume the following model:
+--rw nodes
+--rw node [id]
+--rw id string
+--rw under-lay-attribute-a ???
+---ro nodes-state
+--ro node [id]
+--ro id string
+--ro attribute-a string
I cannot define the under-lay-attribute-a to reference attribute-a as:
type leafref {
path "../node/attribute-a"'
}
>
> BTW, maybe further discussion about a new solution should be on the i2rs ML
> only?
>
>
> /martin
>
>
> >
> > Thanks,
> >
> > - Xufeng
> >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:[email protected]]
> > > Sent: Thursday, February 2, 2017 2:33 AM
> > > To: [email protected]
> > > Cc: [email protected]; [email protected]; draft-ietf-i2rs-yang-l3-
> > > [email protected]; [email protected]; [email protected]
> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> > > draft-ietf-i2rs-yang-l3-
> > > topology-08: (with COMMENT)
> > >
> > > Alexander Clemm <[email protected]> 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:[email protected]] On Behalf Of Alia Atlas
> > > > Sent: Wednesday, February 01, 2017 1:14 PM
> > > > To: Lou Berger <[email protected]>
> > > > Cc: [email protected]; [email protected];
> > > > [email protected]
> > > > 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
> > > > <[email protected]<mailto:[email protected]>> 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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
