Hi  Jorgen,
The reason is that TE topologies (e.g. anstract TE topologies) could be 
(re-)configured by a client, while I2RS topologies could not.
Igor


From:Juergen Schoenwaelder
To:Alexander Clemm,
Cc:Robert Wilton,'Xufeng Liu',[email protected],
Date:2017-06-26 15:13:16
Subject:Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi,

someone needs to explain why the base topology model done in i2rs is
good enough NMDA style while the TEAS extension of it is not. Note
also that people are actively working on NC and RC extensions.

/js

On Mon, Jun 26, 2017 at 05:52:47PM +0000, Alexander Clemm wrote:
> Hi Rob,
> Inline <ALEX>, below
> Thanks
> --- Alex
>
> ---------- Forwarded message ----------
> From: "Robert Wilton" <[email protected]<mailto:[email protected]>>
> Date: Mon, Jun 26, 2017 at 1:53 AM -0700
> Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
> To: "Alexander Clemm" <[email protected]<mailto:[email protected]>>, 
> <[email protected]<mailto:[email protected]>>, "'Nitin Bahadur'" 
> <[email protected]<mailto:[email protected]>>, "'Russ White'" 
> <[email protected]<mailto:[email protected]>>, "'Xufeng Liu'" 
> <[email protected]<mailto:[email protected]>>, 
> <[email protected]<mailto:[email protected]>>, "'Jan Medved 
> (jmedved)'" <[email protected]<mailto:[email protected]>>, 
> <[email protected]<mailto:[email protected]>>, "'Susan Hares'" 
> <[email protected]<mailto:[email protected]>>, "Kent Watsen" 
> <[email protected]<mailto:[email protected]>>, "Martin Bjorklund" 
> <[email protected]<mailto:[email protected]>>
>
>
> Hi Juergen,
>
>
>
>
>
> On 24/06/2017 14:17, Juergen Schoenwaelder wrote:
>
> > On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote:
>
> >> Do you think that it would be useful if the draft also included the extra
>
> >> transient "-state" modules in an appendix (e.g. as per
>
> >> draft-dsdt-nmda-guidelines-01 section 2)?
>
> >>
>
> >> Specifically, I'm thinking to help make the topology module fully usable by
>
> >> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA
>
> >> conventions), until NMDA implementations before widely available.
>
> >>
>
> > Rob,
>
> >
>
> > the less we have of those transient "-state" trees, the better it is.
>
> > For LMAP (in auth48) we did not do this. These extra "-state" trees
>
> > should ideally only be used in very rare cases, I think existing code
>
> > already works with a single tree (at least this is what I understood
>
> > from the OpenDaylight discussions).
>
> I completely agree with you in general, but for the topology module I
>
> think that the -state tree is required to represent topologies that
>
> exist but have not been configured (e.g. perhaps those learned from a
>
> dynamic routing protocol).
>
>
>
> Also copying Kent and Martin, since they were very both very involved in
>
> the discussions on the I2RS alias discussing the structure of the I2RS
>
> network topology module.
>
>
>
> My interpretation is from Xufeng was it is needed for the TE YANG
>
> modules, but if it turns out that it is not actually needed, then that
>
> is also good with me ;-)
>
>
>
> <ALEX>
>
> The need to represent topologies that are learned is certainly there.  It is 
> not exclusive to TE, and I would be surprised if TE YANG modules have an 
> extra need for a separate state tree.  Probably the best person to comment 
> here is Xufeng, but it sounds to me, also per Juergen’s comments, that an 
> extra state tree will _not_ be needed.
>
> </ALEX>
>
>
>
> Thanks,
>
> Rob
>
>
>
> >
>
> > /js
>
> >
>
>

> _______________________________________________
> 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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to