Two specific callouts: Don, please clarify which documents could use further hamornization?
With regard to transport and subscription decoupling, this was a topic that had received some discussion at the NYC netmod interim. It was agreed that this was potentially useful work and while this was a netmod interim, given the crossover of attendees with netmod vs. netconf it was suggested that I2RS should make a proposal as to how such a decoupled mechanism should be represented in netconf. To this point, Alex Clemm, it may be worthwhile expanding your proposal to contain that feature. Please review the minutes and please forgive some unusual typos. I realized that Apple auto-correct was running for a while and I may have failed to catch some of the incorrect substitutions. -- Jeff
I2RS interim, December 16, 2014. 10:00-11:40 ET Attendees: Alia Atlas Amit Dass Ignas Bagdonas Jan Medved Jie Dong Joel Halpern Lixing Wang Robert Varga Nitin Bahadur Alexander Clemm Ace Linden Kent Watsen Don Fedyk Cary FitzGarald Lou Berger Michael Wang Andy Bierman Dan Romascanu Deborah Brungard Juërgen Schönwälder Dhruv Dhody Hariharan Ananthakrishnan Himanshu Shah Xufeng Liu Agendaâ¦. [slides] Traceability draft has been adopted. We dovetail with netconf/netmod ââ Rib Info Yang model - Amit [slides] High level differences. What are unique for i2rs? I2RS - not covering the default rib model, compared to the netmod-cfg they do. Using capabilities for tunnel encap types. Propose add RPC from agent to client for route changes Q: Juergen - why do we need rpc vs. notification Lixing: Example from BGP use case. ⦠Sue: This is for pub-sub, for retrieving history. From BGP use cases. Jan: Do we need both info and data model now? Sue: Alia says one draft. Alia: Thatâs up to WG. IM could proceed separately from DM since weâre not yet rechartered for DM. Jeff: Notification in I2RS. Does it also belong in netmod-cfg? Amit: They should align. Sooner or later, we should come back and revisit it. Alia: Amit and Lixing, very useful comparison vs. netmod rtg-cfg model. Thanks for doing it. Thereâs a recent draft by Eric et al. and motivations for pub-sub. Does it describe the rib model requirements? Useful for i2rs to discuss and netconf to review. Sue: See end presentation. Nitin: Lots of questions raised. Is there a design team to resolve this? Sue: Yes. We are taking volunteers for that team. Nitin: Feel free to add me to it. â Protocol Independent (Topology) Data Models - Sue [slides] Contrast topology dependent vs. independent. PBR - Sits underneath the rib list, above the BNP. Default RIB? PBR needs a default RIB for failover. We are only proposing groups, rules. â Network topology Models - Alex Clemm [slides] Represents both horizontal and vertical layering Lou B: Will you be in Thursdayâs TEAS interim? Alex: Yes. Lou: Will defer. Grappling with issue of control plane topo vs. data plane topology. L3 IGPs theyâre the same. SDN, TE - theyâre not necessarily the same. Sue: PBR is a forwarding data plane focus. Qin will cover service topology and Jie will cover Layer 2. Many people will join you on Thursday. â Yang data model for L2 topology - Jie Dong [slides] Jeff: Your model includes layer 2 physical info (vlan etc.) Does this belong in our I2RS stuff? Alexâs draft lets you look between layers. Do we want this level of detail in our model? Jie: Topo use case draft suggests we want to gather the sum of the info from across the network. What about layer 3/2/1? Agree it needs discussion. Alex: Reasonable to do this. Fine line between abstraction model vs. other info, but not specific to topology. Discuss on case by case basis. If not tied to topology properties, should go to inventory. Jie: Agreed. Sue: As Lou put it we have forwarding layer at l2 and control plane at l2. Alex, when you speak at abstract, which do you mean? Alex: Both. Even with service. Jeff: If we allow write, then the l2 config details matter. Sue: Need active discussions on mail list. Tie into use case. â Service Topology Info Model - Qin Wu (pres. by Bill ?) [slides] Joel: *Who* knows the info needed to populate this model? Service topology needs to be more than just tunnels. Sue: Abstract topology to lay on top of network topology. Weâre describing this using UML. Joel: Starting to cover my questions. Letâs keep going. Lou: I think you made an important clarification. You mean TEAS requests to I2RS. Juergen: Concerned with restconf extensions and netconf extensions being called out in UML. They should work in both. Sue: Thanks for correction, will fix in next rev. [slides] Sue: Note how this ties back to Alexâs model. Additional questions? Lou: Document has TE data. This doesnât get covered in these slides. Is that still there? Sue: We had removed it. Expect to harmoize with Alex. Lou: Usage of TE is not the normal use of it. Perhaps better term, like NAT load balancer, etc. TED is different than normal usage of TED. Sue: I think youâre correct. Weâll update it, happy to take further feedback. Don Fedyk: Theres a lot more commonality in models in layer 3 models and others. They could be harmonize a bit more. XXX - what drafts need harmonization? ââ Subscribing to datastore push updates - Alex Clemm [slides] XXX - transport and subscription decoupling â Simple vs. Complex I2RS - Dean Bogdanovich & Sue (via mailing list) [slides] Joel: This was discussed in WG. Defining granularity at which we conflict shoudl be in model. Not sure what weâre discussing here. Sue: Trying to come to some conclusion about ephemeral database from ietf-91. Dean thought there might be a different way to look at it. Joel: I donât think these things are really primitives. Weâre only interacting with some properties of the interface. Same for route - only changing some property. Jeff: Ex. of route, ownership is internal. Joel: Correct myself from route vs. route-table. Route-table handles that arbitration. Jeff: Russ White basically says just interact with routing table, itâs much simpler. Joel: Have discussed with Russ - donât believe weâve covered the scope properly. Sue: Agree that things are complex, like next hops, recursive nexthops. Letâs have more of this discussion on the list. RFC 6095 may help here, per netconf folk. Don: Distinction is based on ability override something in config vs. the ownership of that thing. Objects that are simple can be easily made to override some properties. Ownership is still in config. Only need this relationship if config is involved. Jeff: Had presented this override picture at last ietf. Covered by option 4 âpanes of glass modelâ. Sue: need to continue this on mailing list. Put more questions out on list. Need to pick this up for Jan 8 meeting. Had hoped this would clarify things.
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
