Linda and all:
I apologize for the delay in responding to this email. I will answer this train of messages one at a time. I apologize if there are any duplicates. <chair hat on> The time for comments on the scope of the I2RS draft-ietf-i2rs-yang-network-topo-01 draft was the adoption time period. The WG has adopted this draft and its direction of a topology with service, L3, L2, and L1. You are correct that the topology independent RIB and Filter-FIB are different than the protocol independent virtual topologies. The I2RS use cases we captured had many virtual topologies with L1 to Service level. </chair hat off> <technical hat on> The virtual use case routing systems do know the full topology - from Layer 1 to Service to reasonably plan the topology changes. The ospf/isis pass link state topology (link, nodes, etc) in BGP because it is useful for a central unit that does topology calculation. The I2RS protocol independent topology (L1, L2, L3, and Service) is similar to this existing work in BGP. I suspect it will be useful central unit that does topology calculation. If this unit is an SDN controller - that is an implementation detail to I2RS. I2RS could write additional nodes or links or termination points into that virtual topology. At this point, there is no request from the data models to write back the protocol independent information to the routing system. Sue From: i2rs [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Friday, June 26, 2015 1:03 PM To: '[email protected]'; [email protected]; Jan Medved (jmedved); [email protected]; [email protected]; Hariharan Ananthakrishnan; [email protected] Subject: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Alex, et al, The I2RS architecture depicts two types of interfaces: - One is the interface between Agent and Client, and - another is the interface between Agent and Routing entities. The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. Cheers, Linda Dunbar
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
