I have been in the same boat but some people thought it is really
important to do a generic topology model in I2RS so here we go.

/js

On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote:
> 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
> >

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to