Subject: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

From: Linda Dunbar <[email-masked]>
Date: Fri, 26 Jun 2015 17:03:25 +0000

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 10:28:02 +0200

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

> _______________________________________________
> i2rs mailing list
> [email-masked]
> 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/>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 29 Jun 2015 14:46:31 +0000

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-masked]] 
Sent: Monday, June 29, 2015 3:28 AM
To: Linda Dunbar
Cc: [email-masked]'; [email-masked]; Jan Medved (jmedved); [email-masked]; [email-masked]; Hariharan Ananthakrishnan; [email-masked]
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 16:53:11 +0200

Linda,

can you please point to the place where this is defined? I do read this
in draft-ietf-i2rs-architecture-09:

  6.  I2RS Agent Role and Functionality

     The I2RS Agent is part of a routing element.  As such, it has
     relationships with that routing element as a whole, and with various
     components of that routing element.

  6.1.  Relationship to its Routing Element

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 29 Jun 2015 16:24:18 +0000

Hi Linda,

thank you for your comments.

Yes, the model concerns interactions between agents and clients.  The nodes in the model refer to the entities that are referred to in the topology - typically the hosting device as a whole, not just the forwarding engine within the device.  The architecture document you mention includes a description of a topology manager in section 5.1; this model will address the need of such application.

The service overlay indicates one way in which the model can be used.  It is intended as an example that illustrates the flexibility of the model.  One key aspect concerns the ability to represent vertical layering relationships; the example shows that the same overlay could map onto several underlays, which is a requirement e.g. when you want to represent a "physical" layering along with logical layering, to know e.g. which physical node/device is supporting a gibven overlay node,  without the need to iteratively traverse through multiple layers.   I am not sure I understand your comment that it "is definitely meant for clients not towards individual nodes".  It is intended to represent relationships between nodes in layered topologies; it would be exposed by an agent to a client.

--- Alex

From: Linda Dunbar [mailto:[email-masked]]
Sent: Friday, June 26, 2015 10:03 AM
To: [email-masked]'; Alexander Clemm (alex); Jan Medved (jmedved); Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco); [email-masked]; Hariharan Ananthakrishnan; Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)
Subject: comments to draft-ietf-i2rs-yang-network-topo-01

Alex, et al,

Cheers,

Linda Dunbar

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Jun 2015 14:01:26 -0400

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

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 29 Jun 2015 18:32:49 +0000

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-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, June 29, 2015 2:01 PM
To: Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan Ananthakrishnan; [email-masked]; [email-masked]; 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:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> Cc: [email-masked]'; [email-masked]; Jan Medved (jmedved); 
> [email-masked]; [email-masked]; Hariharan Ananthakrishnan; 
> [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 29 Jun 2015 21:01:59 +0000

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-masked]] 
Sent: Monday, June 29, 2015 1:33 PM
To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan Ananthakrishnan; [email-masked]; [email-masked]; Jan Medved (jmedved)
Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

I agree with Joel,

Cheers,
Igor

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, June 29, 2015 2:01 PM
To: Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan Ananthakrishnan; [email-masked]; [email-masked]; Jan Medved (jmedved)
Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Jun 2015 17:06:17 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jun 2015 07:41:24 +0200

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:
> >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
> >
> >Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan 
> >Ananthakrishnan; [email-masked]; [email-masked]; Jan Medved (jmedved)
> >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
> >
> >Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan 
> >Ananthakrishnan; [email-masked]; [email-masked]; Jan Medved (jmedved)
> >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,
> >>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
> >>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
> >>
> >>>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
> >>>
> >>>
> >>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 30 Jun 2015 12:48:43 +0000

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-masked]] 
Sent: Monday, June 29, 2015 5:06 PM
To: Linda Dunbar; Igor Bryskin; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan Ananthakrishnan; [email-masked]; [email-masked]; Jan Medved (jmedved)
Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 15:18:57 -0400

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-masked]] On Behalf Of Linda Dunbar
Sent: Friday, June 26, 2015 1:03 PM
To: [email-masked]'; [email-masked]; Jan Medved (jmedved);
[email-masked]; [email-masked]; Hariharan Ananthakrishnan;
[email-masked]
Subject: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

Alex, et al, 

 

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. 

 

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 15:23:06 -0400

Linda and Juergen:

The I2RS client may talk to multiple I2RS agents on multiple nodes or an
I2RS client may talk to only one I2RS agent on one node.  Whether the I2RS
client maintains a network-wide view or a single device view is up to the
I2RS client's implementation. 

The I2RS client to I2RS agent protocol deals with the protocol between one
I2RS client and one I2RS Agent which may exist over multiple transport
connections. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 29, 2015 10:47 AM
To: Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

Juergen, 

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-masked]] 
Sent: Monday, June 29, 2015 3:28 AM
To: Linda Dunbar
Cc: [email-masked]'; [email-masked]; Jan Medved (jmedved);

Linda,

/js

> 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.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 16:23:37 -0400

Linda and all:

<chair hat on>

</chair hat off> 

<technical hat on> 

Sue 

Alex, et al, 

 

 

 

 

Cheers, 

Linda Dunbar

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 16:29:36 -0400

Linda and Juergen:

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 29, 2015 10:47 AM
To: Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

Juergen, 

Linda
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 29, 2015 3:28 AM
To: Linda Dunbar
Cc: [email-masked]'; [email-masked]; Jan Medved (jmedved);

Linda,

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:06:20 -0400

Forwarding to I2RS list due to list restriction. 
Sue 

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 3:23 PM
To: 'Linda Dunbar'; 'Juergen Schoenwaelder'
Cc: [email-masked]'; [email-masked]'; [email-masked]';
'Hariharan Ananthakrishnan'; [email-masked]'; [email-masked]'; 'Jan
Medved (jmedved)'
Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

Linda and Juergen:

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 29, 2015 10:47 AM
To: Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

Juergen, 

Linda
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 29, 2015 3:28 AM
To: Linda Dunbar
Cc: [email-masked]'; [email-masked]; Jan Medved (jmedved);

Linda,

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:06:57 -0400

Forwarding to list. 

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 3:26 PM
To: 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen Schoenwaelder'
Cc: [email-masked]'; [email-masked]'; [email-masked]';

Joel and Juergen: 

My understand of the draft-ietf-i2rs-architecture aligns with yours.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, June 29, 2015 2:01 PM
To: Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:07:20 -0400

Forwarding to list 

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 3:29 PM
To: 'Igor Bryskin'; 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen
Schoenwaelder'

Igor:

You are correct. The interaction between the I2RS agent to routing systems
is considered out of scope of the I2RS protocol and I2RS WG. 

                   IETF I2RS             proprietary
I2RS client ------ I2RS agent----------------routing system 

Sue
-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Monday, June 29, 2015 2:33 PM
To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

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-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, June 29, 2015 2:01 PM
To: Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:07:39 -0400

Forwarding to list. 

Sue 

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 3:31 PM
To: 'Linda Dunbar'; 'Igor Bryskin'; 'Joel M. Halpern'; 'Juergen
Schoenwaelder'

Linda:

Thank you for the feedback on the draft-ietf-i2rs-yang-network-topo-01
draft.  This is useful feedback to the authors as we try to explain the I2RS
work to customers. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 29, 2015 5:02 PM
To: Igor Bryskin; Joel M. Halpern; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

Joel, Igor, Juergen, 

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. 

My two cents. 

Linda 

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Monday, June 29, 2015 1:33 PM
To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

I agree with Joel,

Cheers,
Igor

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, June 29, 2015 2:01 PM
To: Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:08:16 -0400

Forwarding to I2RS list. 

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 3:59 PM
To: 'Igor Bryskin'; 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen
Schoenwaelder'

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-masked]] On Behalf Of Igor Bryskin
Sent: Tuesday, June 30, 2015 8:49 AM
To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

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-masked]]
Sent: Monday, June 29, 2015 5:06 PM
To: Linda Dunbar; Igor Bryskin; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]'; [email-masked]; Hariharan

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

> 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.
> Cc: [email-masked]; [email-masked]'; [email-masked]; 
> Hariharan Ananthakrishnan; [email-masked]; [email-masked]; Jan 
> Medved (jmedved)
> Cc: [email-masked]; [email-masked]'; [email-masked]; 
> Hariharan Ananthakrishnan; [email-masked]; [email-masked]; Jan 
> Medved (jmedved)
>> [email-masked]; [email-masked]; Hariharan 
>> Ananthakrishnan; [email-masked]