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

["Susan Hares" <[e-mail]>]

<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:[e-mail]] On Behalf Of Martin Bjorklund
Sent: Thursday, February 2, 2017 11:18 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi,

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