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

[Rob Shakir <[e-mail]>]

On 19 Mar 2015, at 22:31, Thomas D. Nadeau <[e-mail]> wrote:
> 
> 	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. 
> 

hi Tom,

Just commenting from my personal experience of working on the openconfig models — I tend to agree. what I started to struggle with is:

1) Where should stuff be defined - such that everyone doesn’t end up duplicating it. For example, should we have an interfaces list with all MPLS config in it, or should we have interface configuration under each signalling protocol; how do we capture config for protocols that are almost the same, but have only minor tweaks under them? (IMHO) This has meant that we’ve put some focus into models that look like they’re a no-op from some perspectives, it just gives us a framework within which to work such that we can not duplicate work.

2) Consistency across the models - for example, how do we ensure that programmatic interaction with the model doesn’t need to consider what model it is interacting with. This is really important from an operator perspective, where i expect to be writing N different integrations with these models each time  I need a service that relies on configuring something on the network.

Defining common conventions, and then iterating them as we figure out that there are either limitations in the way we can use YANG; or there are complexities that we didn’t forsee for a certain protocol is the important thing. Whilst doing this we should bear in mind that:

a) doing a bit of thinking here stops us creating an unusable bag-of-bits, that theoretically works really nicely, but doesn’t actually make any sense when operators come and consume it (the network will not be more programmable, unless we can actually remove the pain of writing programs that interact with it, configuration transactionality, and common namespaces are only a couple of the challenges today - there are clearly others).

b) we want to do something quickly - and might not be right with our first estimation of what “right” looks like.

To this end — yes, let’s write something quickly in a wiki or some such, and get to rough consensus and usable code. If we see value in publishing these conventions once they are locked down - then we can make this judgement at the time.

Cheers,
r.



> 	--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
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord