Forwarding to I2RS list. -----Original Message----- From: Susan Hares [mailto:[email protected]] Sent: Tuesday, June 30, 2015 3:59 PM To: 'Igor Bryskin'; 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen Schoenwaelder' Cc: '[email protected]'; '[email protected]'; '[email protected]'; 'Hariharan Ananthakrishnan'; '[email protected]'; '[email protected]'; 'Jan Medved (jmedved)' Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01
Igor and Joel: <individual contributor hat on> I agree with Igor. See the draft-ietf-idr-ls-distribution debates. The argument in these debates is that it was better to pull the information regarding topologies from key nodes within the routing topologies. If you disagree, I encourage you to debate this for the draft-ietf-idr-ls-distribution rather than just for I2RS. If you agree with the draft-ietf-idr-ls-distribution, then the I2RS creation of a topology that is network-wide within a specific node is the same concept. I agree with Igor that I2RS should be modify these topologies beyond by combining learned topologies plus ephemerally configured topologies. However, the exact combination must be spelled out in the I2RS data module. <individual contributor hat off> Sue Hares -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Igor Bryskin Sent: Tuesday, June 30, 2015 8:49 AM To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder Cc: [email protected]; '[email protected]'; [email protected]; Hariharan Ananthakrishnan; [email protected]; [email protected]; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Hi Joel, I agree that there is a difference as to how we deal with RIB and topologies. RIB is a property of a single physical device, while topologies (both routing/reachability and TE) are always network-wide. However, for some applications it is important to extract topologies from a layer 3 switch as they are, for example, learned by the switch's routing protocols. I think of I2RS as a unified interface to a routing system to get everything the system exposes to the outside world. Hence I2RS is a right interface IMHO to extract topologies from a given physical switch. Furthermore, if an I2RS agent represents/manages multiple devices (e.g. SDN controller), it may expose abstract topologies (instead or in addition to its native topologies ) customized on per client basis. If one assumes that said clients can (re-)configure themselves the abstract topologies, then we have the same issues as we have with RIB (conflicting (re-)configurations of a given abstract topology, client priorities and ephemeral state). So why not to resolve all these issues in a similar way ? Cheers, Igor -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Monday, June 29, 2015 5:06 PM To: Linda Dunbar; Igor Bryskin; Juergen Schoenwaelder Cc: [email protected]; '[email protected]'; [email protected]; Hariharan Ananthakrishnan; [email protected]; [email protected]; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 You may recall that I have expressed concern about many times about how the network topology draft fits the I2RS scope. It is still not clear to me that it is an I2RS item, although it is clearly useful for things talking to the I2RS Agent. Yours, Joel On 6/29/15 5:01 PM, Linda Dunbar wrote: > Joel, Igor, Juergen, > > Thanks for the feedback. Actually I always thought I2RS Agent is within a single routing engine until reading the "I2RS Topology" draft. > > I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good specification for information exchange between a routing engine and its client. It reflects one single node's RIBs associated with multiple Routing Instances supported by the routing engine. > > But the "I2RS Topology", which is also a very good specification describing the network view of topologies (which consists of multiple nodes and links among them), is more suited for the entity that manages multiple routing nodes. > > RIBs of one routing engine and "topology of multiple routing engines" definitely represent different perspectives: one is node view, another one is the network view. > > > In order to make I2RS widely adopted by the industry, it is very important not to make it too complicated. Routing is not simple to start with, therefore, it becomes especially more important to keep I2RS specification simple and to the point. > > Therefore, I suggest to have a paragraph in the "network-topo" draft to describe that this is for the network view, it is for clients who manage/monitor multiple routing engines. > > My two cents. > > Linda > > -----Original Message----- > From: Igor Bryskin [mailto:[email protected]] > Sent: Monday, June 29, 2015 1:33 PM > To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > Cc: [email protected]; '[email protected]'; [email protected]; > Hariharan Ananthakrishnan; [email protected]; [email protected]; Jan > Medved (jmedved) > Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > I agree with Joel, > > To answer Linda's question: if I2RS agent manages/represnts multiple physical devices, the interface between the agent and the devices is out of scope of I2RS. Note that such interface needs to be standardized only if one considers a scenario where an I2RS agent controls devices from different vendors. IMHO this scenario is unlikely, and at least for now it is safe to assume that said interface is private. > > Cheers, > Igor > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Monday, June 29, 2015 2:01 PM > To: Linda Dunbar; Juergen Schoenwaelder > Cc: [email protected]; '[email protected]'; [email protected]; > Hariharan Ananthakrishnan; [email protected]; [email protected]; Jan > Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. > > It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, > and an agent may be communicating with multiple clients. But it is > still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. > > Yours, > Joel > > On 6/29/15 10:46 AM, Linda Dunbar wrote: >> Juergen, >> >> One I2RS agent can interface with multiple routing elements. >> >> The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. >> >> Linda >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:[email protected]] >> Sent: Monday, June 29, 2015 3:28 AM >> To: Linda Dunbar >> Cc: '[email protected]'; [email protected]; Jan Medved (jmedved); >> [email protected]; [email protected]; Hariharan >> Ananthakrishnan; [email protected] >> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >> >> Linda, >> >> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. >> >> /js >> >> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>> 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 >> >> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
