Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt

["Thomas D. Nadeau" <[e-mail]>]

> On Mar 20, 2015:1:11 PM, at 1:11 PM, Alia Atlas <[e-mail]> wrote:
> 
> 
> 
> On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Tom,
>> 
>> I am not sure what you are picturing when I use the word "architecture".  My intent is a combination of
>> "an architecture that can suggest and articulate common functionality to be used by multiple models
>>  and how the models interconnect" which I loosely refer to as a "meta-model" plus considerations such
>> as common conventions that are routing specific and thinking about future extensibility and features now.
> 
> 	I am imagining an 18 month process that creates a static document that is out-of-date right around
> that time. What I am advocating for is something more fluid, and iterative that can be used to guide
> the rapid development of models right now.
> 
>> I am not expecting a template of "here's how to write a model"; that seems like it could be interesting for
>> netmod to work on.  I know that netmod is working on rfc6087bis and look forward to seeing the results of
>> that work.
> 
> 	Its not a generic template; its a template and guides for how to write routing models much how the Open Config draft has
> started.
>  
> It's not yet completely clear how many conventions are routing specific vs. generic for writing YANG models.
> What's generic can happen in netmod.  What's specific is something for the planned design team. 
>> I am certainly expecting the design team to deliver at least the "meta-model" part of it before the Prague
>> IETF.  I am also OF COURSE recommending that the design team considering existing work that is done
>> in the space - including the OpenConfig work - and building a design team including people who are actively
>> involved in this area.
> 
> 	The meta model is what I am referring to above as a "template".
> 
> So we are talking about very similar things.  I thought about calling it a "meta-model" but decided that architecture -
> particularly if it includes additional common conventions and so on - was a bit more accurate.   

	I think the term "Architecture" means something different to most people at the IETF.  My first thought was what I've said, for example.  A few others have contacted me privately making the same point, BTW

> 
>> Whether some of this work makes sense to do in a wiki or live as a stable RFC is a different question - but
>> the first point is to get it thought about and written down.
> 
> 	How we approach this is as important if not more important than what we produce. That
> sets the stage for how we move this forward. If we take the canonical RFC approach, that is
> not going to cut it IMHO, as I said above.
> 
> Having it as a wiki versus an internet-draft isn't the primary distinction that I see.  I can see a core piece that we
> believe will be static becoming an RFC while additions and changes happen on a wiki if appropriate.  The main
> part that's critical is that it gets thought about and worked on by motivated people.   A focused group will get
> this moving quickly.  I've seen far too many wikis languish to be convinced that the technology is the critical piece.

	The problem with a draft is that its not readily editable except by the small collection of editors/authors. Theres
also a heavy process with formatting, id-nits, etc...   A wiki is quick and easy. And its easy enough to just paste
the IETF Note Well at the top of that. Once its stabilized someone could push a draft, or at regular intervals during the
process. 

	--Tom

> 
> Regards,
> Alia 
> 
>  
> 	--Tom
> 
> 
>> 
>> Regards,
>> Alia
>> 
>> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Lou and Loa,
>>> 
>>> Thanks for your focus and concern on this.  
>>> 
>>> I share very similar concerns about how to handle the interactions and structure between different
>>> YANG models.  In fact, I am in the process of setting up a routing area design team to write
>>> up a routing yang architecture.  This may also include common conventions and recommendations
>>> for how to handle information to be used by multiple models and so on.
>> 
>> 	Rather than an architecture, I'd suggest something more along the lines of a template for building models.
>> There are a number of reasons why an architecture is the wrong approach here IMHO, but firstly
>> time-to-market is of the essence. We don't want a clan of people spending the next 18 months chugging out
>> what is in effect, a theoretical guide or pattern for how we build models.  Secondly, we have a proposal
>> on the table from a bunch of operators that have built and are actually using the models proposed.
>> I would hate to push that aside for what becomes again, a theoretical discussion that takes
>> 18 months and produces a document.   To be honest, the best approach for this would be a wiki page
>> that gets pinned on the Yang Doctor's wiki, if you ask me. 
>> 
>> 	--Tom
>> 
>> 
>>> At the Routing WG Chairs lunch, one of the topics will be discussing how to coordinate and handle
>>> the various proposed YANG models and the overlaps.
>>> 
>>> One of the useful aspects of this particular model is that it's looking at it from a "what does it do for me" perspective instead of a "here's what the protocol knobs are".  Of course, that doesn't address many 
>>> of the questions around multiple uses of the same technology for different purposes or how to handle
>>> different feature sets being implemented.
>>> 
>>> I am somewhat reluctant to request breaking up of a model into multiple drafts simply to accommodate
>>> the IETF Working Group structure - if it doesn't also improve the models or make it easier to get really
>>> good reviews.
>>> 
>>> So, in short - let's have some good discussion on this, work towards having an architecture with meta-model
>>> for at least routing, and see what makes the most sense.
>>> 
>>> Thanks,
>>> Alia
>>> 
>>> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson <[e-mail] <mailto:[e-mail]>> wrote:
>>> Lou,
>>> 
>>> I take this to mean:
>>> "Yes, we can take the discussion as suggest below in Dallas, but we also
>>>  need a discussion on the [e-mail] <mailto:[e-mail]>, possibly before,
>>>  during and after the Dallas meeting."
>>> 
>>> I agree to that!
>>> 
>>> /Loa
>>> 
>>> 
>>> On 2015-03-19 14:59, Lou Berger wrote:
>>> 
>>> 
>>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>>> All,
>>> 
>>> This of course triggered the obvious question - "What is your plan"?
>>> 
>>> So what I'd like to to see for draft-openconfig-mpls-consolidated-model
>>> discussions in Dallas is
>>> 
>>> - that the discussion on the overall structure goes to the rtgwg
>>> 
>>> - that the technology specific parts are discussed in the relevant
>>>     working group; it see the following wg's that (should) have an
>>>     interest in this
>>>     - teas
>>>     - mpls
>>>     - spring
>>>     - i2rs (?), this might be more of an interest in the overall
>>>       structure.
>>> 
>>> For mpls this discussion will take place on Friday, if we during the
>>> week can agree on a plan forward, and we need time to socialize that
>>> I think there are a few minutes available in the mpls meeting do that.
>>> 
>>> So the general questions I see / have, which are wider than the scope of
>>> this draft, are:
>>> 1. how does the whole control plane (including te+non-te signaling and
>>> routing) picture fit together and relate to other/existing models?
>>> 2. how do all the different topology/service models fit together?
>>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>>> (LSPs)?
>>>     (Yes this assumes that there isn't a full model per controlled
>>> technology.)
>>> 
>>> I think different WGs are/can be involved in addressing these.  As I
>>> said before, I personally care more about these being discussed then
>>> where they are discussed.  I like your plan as it provides a place to
>>> catch any topics not already covered earlier in the week.
>>> 
>>> In the interim, it would be good to start on the actual discussions on
>>> this (or whichever appropriate) list.
>>> 
>>> Lou
>>> /Loa
>>> 
>>> 
>>> 
>>> On 2015-03-19 10:24, Loa Andersson wrote:
>>> Folks,
>>> 
>>> I have not seen any reaction to this, what is the plan?
>>> 
>>> /Loa
>>> 
>>> On 2015-03-18 17:45, Lou Berger wrote:
>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>> thread/draft (as well as relive some of the overall time constraints. )
>>>     My understanding is that the overall structure  &  base document will
>>> be discussed there, while the other WG-specific information / sub-models
>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>> 
>>> Alia/ADs/Authors,
>>> 
>>> Can you confirm?
>>> 
>>> Thanks,
>>> Lou
>>> 
>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>> RTGWG agenda is already jam packed - no room for any additions.
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
>>> 
>>> 
>>> -- 
>>> 
>>> 
>>> Loa Andersson                        email: [e-mail] <mailto:[e-mail]>
>>> Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
>>> Huawei Technologies (consultant)     phone: [phone] <tel:%2B46%20739%2081%2021%2064>
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
>> 
>> 
> 
>