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 protected]>
> wrote:
>
> 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 protected]]
> Sent: Thursday, July 02, 2015 8:55 AM
> To: Juergen Schoenwaelder
> Cc: Joel M. Halpern; b nitin; [email protected]; [email protected]; Hariharan
> Ananthakrishnan; [email protected]; [email protected]; Igor Bryskin; Linda
> Dunbar; Jan Medved (jmedved)
> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01
>
>
>> On Jul 2, 2015:2:51 AM, at 2:51 AM, Juergen Schoenwaelder
>> <[email protected]> wrote:
>>
>> True in principle but then there is apparently also confusion about
>> scope and relationship of the work to what is called an I2RS agent.
>
> That is for sure.
>
>> 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.
>
> 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?
>
>> 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.
>
> For sure.
>
> —Tom
>
>
>
>>
>> /js
>>
>> On Wed, Jul 01, 2015 at 08:41:09AM -0400, Nadeau Thomas wrote:
>>>
>>> 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 protected]> 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
>>>>
>>>> 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
>>>
>>
>> --
>> 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
