Hi Xian, Responding on item 6 inline below. Thanks,
- Xufeng From: Alexander Clemm (alex) [mailto:[email protected]] Sent: Friday, October 09, 2015 8:21 PM To: Zhangxian (Xian); Xufeng Liu; Susan Hares; [email protected] Cc: 'Jeffrey Haas'; TEAS WG; 'Alia Atlas' Subject: RE: [i2rs] WG LC for Topology (10/1 to 10/14) Hi Xian, responses inline, <ALEX> Thanks --- Alex From: i2rs [mailto:[email protected]] On Behalf Of Zhangxian (Xian) Sent: Thursday, October 08, 2015 7:20 PM To: Xufeng Liu <[email protected]<mailto:[email protected]>>; Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: 'Jeffrey Haas' <[email protected]<mailto:[email protected]>>; TEAS WG <[email protected]<mailto:[email protected]>>; 'Alia Atlas' <[email protected]<mailto:[email protected]>> Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) Hi, Xufeng, Alex, Thank you for taking the effort to work toward getting aligned as discussed in last meeting. I have some comments on some of the conclusions. Could you share a bit more on reasons behind Point 3 conclusion? <ALEX> The reason is that the schedule stuff, while generic / non-specific to any specific topology, is not “common”, i.e. does not apply to all topologies/ every instantiation of the model. The goal is to have ietf-network-topology refer to the stuff that is truly common. </ALEX> For points 4 and 5, I think they are related. My understanding is that for ietf-network, it does not follow the method taken by YANG modules such as ietf-interface and ietf-te-topology, in which each �Crw leaf will have a corresponding �Cro leaf. Instead, it choose to use the “server-provided” attribute to say whether all the leafs in the module is configurable or state. I am not sure I understand the conclusion of these two points. Do you agree that both methods are acceptable? <ALEX> There is no operational data defined. The server-provided attributed guides whether network topology information is populated by the server or by the client application, but the information is the same �C this not the config vs oper data (read: stats) separation. To add stats, you should provide an additional subtree/branch as applicable when you are augmenting. </ALEX> One last comment on point 6: is this for future-proofness or you have already have some attributes in mind that can apply to all networks? <ALEX> I’ll let Xufeng respond to that one. We did not have a top-level container because it keeps paths shorter (one less level in the hierarchy) and because if you wanted to insert something at the “top level”, you could always do it in parallel. I still think this is the design that’s preferable. That said, having a top-level container may not really hurt. There were concerns regarding the ramification to existing implementations of the model (notably, Open Daylight) if we were to add it but it seems the fallout would be manageable. Thanks, Alex (end of my comments) </ALEX> [Xufeng] This is for both future-proofness and current requirement. To allow operator easily configure TE topology attributes, we are defining templates that can be applied to all networks. Thank you, Xian From: i2rs [mailto:[email protected]] On Behalf Of Xufeng Liu Sent: 2015年10月9日 4:15 To: Susan Hares; [email protected]<mailto:[email protected]> Cc: 'Jeffrey Haas'; 'Alia Atlas' Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) Hi Folks, The following is an update on the ongoing I2RS<=>TE Topology alignment discussion (between the authors of the TE Topology model and Alex). The issues / solutions that are currently being discussed are: I2RS Generic Network Topology Model (draft-ietf-yang-network-topo): 1. Some groupings in ietf-network.yang and ietf-network-topology.yang cannot be used in augmenting module because of missing name spaces, such as “path "/network/network-id" at line 42 of ietf-network.yang. Solution: Proposed fixes have been sent to Alex to verify. 2. “leaf network-ref” in ietf-network-topology.yang:169, 220, is causing pyang validation errors. Solution: Alex will check the errors. 3. Can the group of schedule attributes be moved from ietf-te-topology.yang to ietf-network-topology.yang? Solution: We agreed to keep them in ietf-te-topology.yang. 4. How to support state branch in augmenting module? Solution: Keep base model ietf-network-topology.yang as is. In the augmenting module, for each entity like topology, node and link, create a config container for configuration attributes and a state container for operational state attributes. 5. Should “server-provided” flag be used to block user operation on read-only entities? Solution: Keep base model ietf-network-topology.yang as is. TE topology will use other means to achieve such a purpose. 6. Should I2RS Generic Network Topology model have a top-level container? The benefit of doing so is to provide an augmentation target node to define attributes global to all networks. Solution: I2RS Generic Network Topology module authors will consider making “/networks” as the top level container. L3 Topology Model (draft-ietf-i2rs-yang-l3-topology) 1. L3 Topology Model should have references to TE Topology model, so that the related TE information can be properly retrieved, when L3 topology and TE topology are congruent. Solution: L3 Topology Model authors will need to update the model and draft to include these. L2 Topology Model (draft-ietf-i2rs-yang-l2-topology) 1. L2 Topology Model should have references to TE Topology model, so that the related TE information can be properly retrieved, when L2 topology and TE topology are congruent. Solution: This needs to be discussed with L2 Topology Model authors. Regards, - Xufeng (on behalf of the authors of the TE Topology Model) From: i2rs [mailto:[email protected]] On Behalf Of Susan Hares Sent: Thursday, October 01, 2015 6:42 PM To: [email protected]<mailto:[email protected]> Cc: 'Jeffrey Haas'; 'Alia Atlas' Subject: [i2rs] WG LC for Topology (10/1 to 10/14) This begins a 2 week WG Last call (10/1 to 10/14) draft-ietf-yang-network-topo �C modeling draft http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ draft-ietf-i2rs-yang-l3-topology �C L3 topology http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ draft-ietf-i2rs-yang-l2-topology �C L2 topology http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/ Implementation status: This an OpenDaylight (ODL) implementation of the L3 topology and general model. It is likely the L2 topology model will be supported in future ODL implementations. Jeff and I would appreciate anyone who has implementations of these topology models to provide details on list or offlist to the chairs. Sue Hares
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
