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

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Jun 2015 16:24:25 -0400

Let me be real clear.  I know that the topology draft is an adopted I2RS 
working item, and I do not expect that to change.  I am not asking that 
it change.  I think it was a bad fit for our scope, but so be it.

I felt I had to say something when someone said "but I2RS architecture 
looks like X because we have the topology draft."

Having the draft does not change the WG agreed architecture.  Which you 
have confirmed in separate email.

Yours,
Joel

On 6/30/15 3:41 PM, Susan Hares wrote:
> Joel:
> <wg draft author hat on>
> The use cases have lots of virtual topologies, and I not received any
> feedback on these use cases. It would useful for you to comment on which of
> these use cases you do not feel is useful.
> <wg draft author hat off>
>
> <wg chair hat on>
> Joel - it sounds like you are questioning the protocol independent topology
> is appropriate for the charter of I2RS.  Charter questions are appropriate
> only during charter adoption. The charter has been adopted in March 2015.
> If you felt you were not heard during this discussion, please send a note to
> the chairs and copy the AD.   The I2RS chairs need to discuss re-opening
> charter issues with the I2RS AD (Alia Atlas).
>
> The time to discuss the scope of the draft-ietf-i2rs-yang-network-top-01
> draft aligning with the charter was during adoption. I do not perceive that
> you are questioning whether this draft aligns with the charter.
> <wg chair hat off>
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> 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
>
> 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-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,
>>
>> 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:
>>> 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
>>>
>>> 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-masked]
>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jun 2015 22:40:05 +0200

Sue,

I agree with Joel.

/js

On Tue, Jun 30, 2015 at 03:43:30PM -0400, Susan Hares wrote:
> Juergen:
> 
> Please comment on which of the virtual topology use cases in the I2rs use
> case requirements document are not appropriate.  As the editor, I'd love
> comments on the draft.   As WG input, this guides the chair's acceptance of
> work. 
> 
> Sue 
> 
> From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, June 30, 2015 1:41 AM
> To: Joel M. Halpern
> Ananthakrishnan; [email-masked]; [email-masked]; Igor Bryskin; Linda
> Dunbar; Jan Medved (jmedved)
> 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
> > 
> > >Thanks for the feedback. Actually I always thought I2RS Agent is 
> > >within a single routing engine until reading the "I2RS Topology" draft.
> > >
> > >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.
> > >
> > >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.
> > >
> > >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 
> > >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
> > >
> > >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,
> > >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
> > >
> > >>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.
> > >>>
> > >>>
> > >>>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
> > >>>
> > >>>
> > >>
> -- 
> 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/>
> 

-- 
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: Nadeau Thomas <[email-masked]>
Date: Wed, 1 Jul 2015 08:41:09 -0400

I personally think its important to do a generic topology model as well as provide a layered model.  This is something that has and is implemented and deployed, so it is clearly important and useful. Where its done is nearly irrelevant just as long as it gets done. 

	—Tom

> On Jun 30, 2015:1:41 AM, at 1:41 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> 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
> 
>> 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
>> 
>>> client. It reflects one single node's RIBs associated with multiple 
>>> Routing Instances supported by the routing engine.
>>> 
>>> nodes and links among them), is more suited for the entity that manages 
>>> multiple routing nodes.
>>> 
>>> 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
>>> 
>>> is that the relationship between I2RS Clittns and I2rS agents is N:M.  
>>>> [email-masked]; [email-masked]; Hariharan Ananthakrishnan;
>>>> [email-masked]
>>>>> 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.
>>>>> 
>>>>> 
>>>>> 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.
>>>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Jul 2015 08:51:58 +0200

True in principle but then there is apparently also confusion about
scope and relationship of the work to what is called an I2RS agent.

My proposal back then was to charter a short-lived WG to produce a
generic topology model so that this important piece of work is not
tied to any other WG with its specific scope.  This proposal did not
fly but I still believe this would have been the cleanest approach.

Anyway, good to read that topology people plan to get together in
Prague. Getting the right people to sit together is at the end what
makes work move ahead.

/js

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 2 Jul 2015 08:54:57 -0400

> On Jul 2, 2015:2:51 AM, at 2:51 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	That is for sure.

> fly but I still believe this would have been the cleanest approach.

	I would be all for this at this point.  Pruning down the 
scope of topology to fit into the current I2RS box (which I disagree with)
does not seem to be working out well in terms of the topo work
at the IETF.  Due to this mismatch, those interested in topology will find
that outside projects such as ODL have progressed topology well beyond 
what is being discussed in i2rs.  For example, multi-layered topology is
a reality and there is a functional implementation of this.  Maybe
the solution is to indeed pull topology out of the i2rs WG and let it progress
independently?

> Prague. Getting the right people to sit together is at the end what

	For sure. 

	—Tom

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 2 Jul 2015 13:19:20 +0000

Tom,

I hope you are aware of the work we are doing in the TEAS working group, which develops a YANG Abstract TE Topology model, which does support multi-layer TE topologies (both native and abstract/customized, both learned and configurable) with layer specific augmentations in the road map. We want this model to be part of the I2RS family, but we also want the model to be used outside of I2RS, for example, in the ACTN context.

 We are also working on a multi-vendor interop event based on the model, which we hope to make happen within 2015.

Cheers,
Igor

-----Original Message-----
From: Nadeau Thomas [mailto:[email-masked]] 
Sent: Thursday, July 02, 2015 8:55 AM
To: Juergen Schoenwaelder
Cc: Joel M. Halpern; b nitin; [email-masked]; [email-masked]; Hariharan Ananthakrishnan; [email-masked]; [email-masked]; Igor Bryskin; Linda Dunbar; Jan Medved (jmedved)
Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01

	That is for sure.

> fly but I still believe this would have been the cleanest approach.

	I would be all for this at this point.  Pruning down the scope of topology to fit into the current I2RS box (which I disagree with) does not seem to be working out well in terms of the topo work at the IETF.  Due to this mismatch, those interested in topology will find that outside projects such as ODL have progressed topology well beyond what is being discussed in i2rs.  For example, multi-layered topology is a reality and there is a functional implementation of this.  Maybe the solution is to indeed pull topology out of the i2rs WG and let it progress independently?

	For sure. 

	—Tom

>>>> 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
>>>> 
>>>>> specification for information exchange between a routing engine 
>>>>> and its client. It reflects one single node's RIBs associated with 
>>>>> 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.
>>>>> 
>>>>> 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
>>>>> 
>>>>> 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
>>>>> 
>>>>> Juergen is correct that by the I2RS definition an I2RS Agent is 
>>>>> part of, and associated with, a single routing element.
>>>>> 
>>>>> 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.
>>>>> 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
>>>>> 
>>>>>> 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?
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> about the topology information, instruct routes to routing 
>>>>>>> engine of multiple nodes, and retrieve link & termination points 
>>>>>>> status from each of those nodes.
>>>>>>> 
>>>>>>> clients not towards individual nodes. Mixing them all together make it confusing.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Linda Dunbar
>>>>>>> 
>>>>>>> 
>>>>>>

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 2 Jul 2015 09:53:46 -0400

Yes, the question is: how does this work with/collide with what is going on in i2rs - and more importantly, how do these models work with the implementations that are out there?

	—Tom

> On Jul 2, 2015:9:19 AM, at 9:19 AM, Igor Bryskin <[email-masked]> wrote:
> 
> Tom,
>