<chair hat on> Martin is right. It should take off IESG and just be I2RS. The document has been sent back to WG by Alia.
Sue <chair hat off> Can add TEAS if Lou or Xufeng desires... -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Martin Bjorklund Sent: Thursday, February 2, 2017 11:18 AM To: [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. > 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. > 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. 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
