I2RS interim, December 16, 2014. 10:00-11:40 ET Attendees: Hariharan Ananthakrishnan Alia Atlas Ignas Bagdonas Nitin Bahadur Lou Berger Andy Bierman Deborah Brungard Alexander Clemm Amit Dass Dhruv Dhody Jie Dong Jan Medved Jie Dong Don Fedyk Cary FitzGarald Jeff Haas Joel Halpern Susan Hares Ace Linden Xufeng Liu Jan Medved Dan Romascanu Juërgen Schönwälder Himanshu Shah Robert Varga Lixing Wang Michael Wang Kent Watsen Qin (Bill) Wu Agenda Discussion on I2RS RIB Info Drafts [10:00 - 10:30 (zctual)] discussing: 1) Interaction between RIB Yang Model and draft-ietf-netmod-routing-cfg 2) Nexthop structures proposed in RIB Info Model [draft-ietf-i2rs-rib-info-model-04] Discussion of I2RS topology drafts [10:30 - 11:15] Overview and PBR {Sue Hares] [10:30 - 10:35] Yang Model for Network Topologies: [Alexander Clemm] [10:35-10:45] draft-clemm-i2rs-yang-network-topo-01.txt draft-clemm-i2rs-yang-l3-topo Yang Model for L2 Topologies [Jie Dong] [10:45 - 10:50] draft-dong-i2rs-yang-l2-network-topology Yang Model for Service Topologies [Qin Wu/Sue Hares] [10:50 - 11:00] http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/ Discussion on topology drafts [10:35 - 10:45] Protocol Discussion: [11:05 - 11:30] 1) Simple protocol option - [Dean Bogdanovic] 2) Complex Protocol option - [Sue Hares] 3) pub-sub option [Alexander Clemm, Eric Voit] ================== I2RS Adoption calls in December-January I2RS will make an adoption call for RIB Yang/IM model after 12/16/2014 meeting. Topics for 1/8/2015 and 1/23/2015 I2RS interim: 1) Protocol Requirements for I2RS 2) Topology drafts 3) RIB Info drafts. 1) Document status: Traceability draft has been adopted. We dovetail our Yang modules with netconf and netmod. ==== 2) Rib Info Yang model - Amit [slides] High level differences. What are unique for i2rs? I2RS is 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. ===== 3) Protocol Independent (Topology) Data Models - Sue [slides] 3.1 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. ------ 3.2 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. ------- 3.3 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. 3.4 Service Topology Info Model - Qin Wu and Sue Hares [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 harmonize 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: There is a lot more commonality in models in layer 3 models and others. They could be harmonize a bit more. Jeff: What is the additional harmonization My point was the Yang Model for L3 (as presented) seemed to outline L3, Service and Optical and missed L2 totally. (Not saying this is one document but one architecture as presented). Then the L2 Presentation had some L2 but missed several L2 capabilities. (VPLS, EVPN, VXLAN, PBB etc.) If you look at this more generically each layer (l3,l2,l1) has: Data path, Tunneling/Multiplexor/Virtual network, Topology, Topology data base, TE extensions, Control Plane. Each layer can and may use IS-IS or OSPF (and even BGP) for some address distribution VPN information, connection coordination, TE information, within the context of an Instance/VPN. Each layer can and may offer a service, p2p, p2mp, mp2mp,(some type of persistent connection or set of connections that may have their own resiliency mechanisms) at the layer or up to a higher layer. Layers can be skipped and upper layers may be unaware of lower layers. Lou Berger (from email response): My comment on control plane vs data plane is very much in line with this comment. And Don has begun some of the discussion I was hoping to talk a bit more about in Thursday's TEAS interim. (At least the TE aspects, as well as the possible formal representation of control plane separately from data plane.) —— Subscribing to datastore push updates - Alex Clemm [slides] XXX - transport and subscription decoupling — Simple vs. Complex I2RS - Dean Bogdanovich and Sue (via mailing list) [slides] Joel: This was discussed in WG. Defining granularity at which we conflict should be in model. Not sure what we’re discussing here. Sue: Trying to come to some conclusion about ephemeral database from ietf-91. Dean Bogdanovic 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: Example 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 is much simpler. Joel: Have discussed with Russ - who does not believe we have covered the scope properly. Sue: Agree that things are complex, like next hops, recursive nexthops. Let us have more of this discussion on the mail 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. We had hoped this discussin would clarify things, but we need to go a few more rounds.