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

[Alia Atlas <[e-mail]>]

On Fri, Mar 20, 2015 at 1:34 PM, Thomas D. Nadeau <[e-mail]>
wrote:

>
> 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]
> > wrote:
>
>>
>> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <[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
>

I found the term "template" to be equally confusing.  The design team
charter has the description that I included.  I'm waiting to
get a few comments back, but expect to make a first version public during
next week.

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.
>

How the design team chooses to organize getting its work done is up to
them.  I'm not in the business of micro-management.
Without a fairly small focused group, it is hard to get serious and rapid
progress.  Work can sometimes suffer by being
too criticized while still in the brainstorming stage.  How open the design
team chooses to be is going to be up to them to
decide how best they can make progress.  Certainly, there are many ways to
work and pros and cons to each.

Regards,
Alia


> --Tom
>
>
> Regards,
> Alia
>
>
>
>> --Tom
>>
>>
>>
>> Regards,
>> Alia
>>
>> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <
>> [e-mail]> wrote:
>>
>>>
>>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <[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]> 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], 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]
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rtg-yang-coord mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>
>>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: [e-mail]
>>>> Senior MPLS Expert                          [e-mail]
>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>
>>>
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>
>>>
>>>
>>
>>
>
>