Re: [Lsr] When to augment LSR base YANG modules...

2019-04-16 Thread bruno.decraene
Sent: Tuesday, April 16, 2019 9:52 AM To: Christian Hopps; lsr@ietf.org Subject: Re: [Lsr] When to augment LSR base YANG modules... Hi, On one hand, I'm a bit worried about having too many tiny modules (finding the right module name to get the right feature, managing prefixes...). The good thin

Re: [Lsr] When to augment LSR base YANG modules...

2019-04-16 Thread stephane.litkowski
alf Of Christian Hopps Sent: Friday, March 29, 2019 09:17 To: lsr@ietf.org Cc: cho...@chopps.org Subject: [Lsr] When to augment LSR base YANG modules... The base YANG modules for IS-IS and OSPF both include operational state to describe TLV data. During the discussion about OSPFv3's version of this data

Re: [Lsr] When to augment LSR base YANG modules...

2019-04-05 Thread Kristian Larsson
On 2019-04-02 12:08, tom petch wrote: - Original Message - From: "Mikael Abrahamsson" Sent: Sunday, March 31, 2019 8:07 AM On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: Additionally, I agree with Yingzhen's comment that it is not clear that we want a separate YANG module for

Re: [Lsr] When to augment LSR base YANG modules...

2019-04-02 Thread tom petch
- Original Message - From: "Mikael Abrahamsson" Sent: Sunday, March 31, 2019 8:07 AM > On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: > > > Additionally, I agree with Yingzhen's comment that it is not clear that > > we want a separate YANG module for every OSPF/IS-IS feature. > > As an

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Acee Lindem (acee)
y, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' , "'Acee Lindem (acee)'" > Cc: "lsr@ietf.org" , "tony...@tony.li" , 'Christian Hopps' > Subject: Re: [Lsr] When to augment LSR base YANG modules... > > Rob and Acee: >

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Christian Hopps
n return? Thanks, Chris. > > Thanks, > Yingzhen > > From: Lsr on behalf of Susan Hares > Date: Sunday, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' , "'Acee Lindem (acee)'" > Cc: "lsr@ietf.org" , "tony...@tony.li" , > 'Christian Hopps' > S

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Yingzhen Qu
tian Hopps' Subject: Re: [Lsr] When to augment LSR base YANG modules... Rob and Acee: I agree that with Rob that it is a generic problem that you must have a robust way to version and revise the Yang models. This is true for configuration, operational data, and dynamic data stores. T

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Susan Hares
[mailto:lsr-boun...@ietf.org] On Behalf Of Rob Shakir Sent: Saturday, March 30, 2019 2:00 PM To: Acee Lindem (acee) Cc: lsr@ietf.org; tony...@tony.li; Christian Hopps Subject: Re: [Lsr] When to augment LSR base YANG modules... I think this is a generic challenge that has to be solved across all

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Christian Hopps
So to have something to look at while we discuss this I wrote a bare-bones module document for IS-IS reverse metrics: https://tools.ietf.org/html/draft-hopps-lsr-yang-isis-reverse-metric-00 If you look at the meat of that document and then imagine including it as an appendix or whatever

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Mikael Abrahamsson
On Sat, 30 Mar 2019, Rob Shakir wrote: That being said -- this means one should probably expect each LSR base module to be revised with most new LSR RFCs. With the current agility of the review and publication process -- I'm not sure that is realistic either.. I have discussed this with

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-31 Thread Mikael Abrahamsson
On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: Additionally, I agree with Yingzhen's comment that it is not clear that we want a separate YANG module for every OSPF/IS-IS feature. As an operator, I expect to manage my routers using YANG modules. Thus, every feature that is introduced that

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-30 Thread Rob Shakir
I think this is a generic challenge that has to be solved across all protocols -- and relies on a robust way to version and revise YANG modules in the IETF. In OpenConfig, as we're very lightweight for pushing a new revision, since we're just specifying new versions of modules, adding new

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-30 Thread Acee Lindem (acee)
Speaking as WG member: For many of the new LSR WG documents, we are already included both OSPF and IS-IS encodings in a single document. Now, we have agreed that documents requiring simple BGP-LS changes will also include the BGP-LS encoding. Given this, I don't want to add another requirement

Re: [Lsr] When to augment LSR base YANG modules...

2019-03-29 Thread tony . li
Chris, One concern is simply one of scale: doing this will increase the size of the document. At what point do things become sufficiently awkward that we want to have a separate, concurrent document. In other words, if the requirement is for concurrent delivery, is co-location really a

[Lsr] When to augment LSR base YANG modules...

2019-03-29 Thread Christian Hopps
The base YANG modules for IS-IS and OSPF both include operational state to describe TLV data. During the discussion about OSPFv3's version of this data, I brought up the issue of when and how the base modules should be augmented to add new TLV types to the model, suggesting it be done inline