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

From: Lou Berger <[email-masked]>
Date: Fri, 13 Mar 2015 06:44:36 -0400

Authors,

Nice bit of work here. It has a pretty comprehensive scope and touches a 
few wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize 
this work, what are your thoughts / plans on how you are going to break 
down the work into different pieces and WGs?

Thanks,
Lou

--- Forwarded message ---
From: [email-masked]
Date: March 9, 2015 6:49:56 PM
Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
To: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : MPLS / TE Model for Service Provider Networks
        Authors         : Joshua George
                          Luyuan Fang
                          Eric Osborne
                          Rob Shakir
	Filename        : draft-openconfig-mpls-consolidated-model-00.txt
	Pages           : 47
	Date            : 2015-03-09

Abstract:
   This document defines a framework for a YANG data model for
   configuring and managing label switched paths, including the
   signaling protocols, traffic engineering, and operational aspects
   based on carrier and content provider operational requirements.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Mar 2015 18:26:18 -0400

Josh,

see below.

On 3/16/2015 2:51 PM, Joshua George wrote:
> Hi Lou,
>
> Thanks for the note and kind words.
>
> We've been nearly exclusively focused on the content and structure of
> the draft so far, and haven't yet given a lot of thought to the
> administrative component of it.
a very reasonable approach.

> Our initial thought was to present to both mpls and teas, and then
> decide based on the feedback where to direct updates.
>
> However, we'd be grateful for any thoughts or suggestions you have on
> finding the right home for it. Please let us know.
>

It's not clear to me that there is/should be one home for the whole
scope of the draft. Parts are clearly within the scope of a single WG
(e.g., segment-routing specifics seems to belong in SPRING,
unconstrained-path and LDP seems to belong in MPLS, and
constrained-path, and RSVP seems to belong in TEAS) while the overall
structure will need a home and could fall into the scope of a few
different WGs (perhaps RTG WG, I2RS or ???). 

>From my personal perspective I think it's most important to agree on an
overall structure that allows the different WG groups to make progress
in parallel.  I suspect the right folks to contribute to such an
agreement are already on this list. 

Which working group drive's the process is a bit secondary to me, and I
think the ADs ultimately get to make that call.

Does this make sense?

(Any other opinions out there? ;-)

Thanks,
Lou
> Thanks!
>
> --josh
>
> On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Authors,
>
>     Nice bit of work here. It has a pretty comprehensive scope and
>     touches a few wgs (mpls, teas, perhaps rtgwg...). Assuming your
>     plan is to stanardize this work, what are your thoughts / plans on
>     how you are going to break down the work into different pieces and
>     WGs?
>
>     Thanks,
>     Lou
>
>
>     From: [email-masked] <mailto:[email-masked]>
>     To: <[email-masked] <mailto:[email-masked]>>
>
>
>             Filename        :
>     draft-openconfig-mpls-consolidated-model-00.txt
>             Pages           : 47
>             Date            : 2015-03-09
>
>     Abstract:
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 17 Mar 2015 09:09:37 +0100

Lou, Josh, et.al.,

> think the ADs ultimately get to make that call.

Hmmm - make the call is fine, but I guess that this is and the union of
the wg chairs of the wg's you listed (teas, mpls, i2rs, rtg, spring,
etc.) needs to try to converge before the call is made.
> Does this make sense?

Makes sense to me. Just now we have a presentation on the MPLS agenda,
since time is the scarce thing during the IETF week, I don't think we
should present it more than in one place.

We have it on Friday, together with the rest of the mpls-yang
discussion. We can keep it on our agenda and have every other group
point to that discussion. Makes sense to me since we can use the
week for off-line and mailing list discussion and try to come up
with some educated approximation of a plan on Friday.

/Loa

> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Mar 2015 11:01:14 -0400

Loa,
    See below.

> etc.) needs to try to converge before the call is made.

Not sure why,but I leave it to the ADs either way.

> should present it more than in one place.

Actually, I may disagree.  I do agree that having popup discussions on
the same (overal structure) topic isn't too helpful.  But, I think
having the relevant portion of the document presented in the relevant WG
(with some context of course) makes the most sense.   If your comment
was directed at the former, than I'm in complete agreement.

> with some educated approximation of a plan on Friday.

TEAS also has a slot on it's agenda for the draft.  My expectation (as
chair) most of the time will be spent discussing the WG-related portion
of the document that overlaps other individual documents that are also
being discussed, and perhaps also how the in-WG scope models tie into
other models.  IMO omitting this draft from our Dallas discussions would
hurt WG progress on the topic. 

I'm not expecting to cover the out of scope portions of the draft in our
TEAS meeting in Dallas, and interest in the overall structure discussion
let me to start this thread.

Lou

---

From: Loa Andersson <[email-masked]>
Date: Tue, 17 Mar 2015 16:46:21 +0100

Lou,

>      See below.
<snip>

> Not sure why,but I leave it to the ADs either way.

Hmmm - the work you been doing here - driving the consensus in the
involved working groups are for the wg chairs, if we need a higher
level of "calling the consensus" that might be for the ADs.

> was directed at the former, than I'm in complete agreement.

I was thinking about repeating the same discussion in more than one wg.

I'm struggling a bit to understand what you are saying. While I can
understand the formula "relevant piece of the to the relevant wg", this
is not what I see happening. What we have in the agendas posted today
is that mpls and teas have slots, but you say the draft (or pieces of
the draft) are relevant also at least to rtgwg, spring and i2rs, and
there are currently no agenda slots for that discussion in those
wg's, neither am I sure that splitting it up that much is most
productive.

To discuss the home(s) of the document, I think the entire scope should
be on the able somewhere (at least on some table somewhere during the
week).

So I'm wondering a bit about what instructions to give the authors for
the discussion in mpls.

We could tell them "give us some context, but for the rest keep to what
is strictly relevant for MPLS" or we could say "give us some context,
discuss what is relevant for MPLS and also bring up what you feel you
has not had opportunity to discuss in any other wg during week and we
will take this as a basis for discussing what will happen with the
document on this list".

Currently I'm in favor of the second alterntive, but I'm open to
discuss any other plan.

/Loa
> let me to start this thread.
<snip>

--

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Mar 2015 12:11:26 -0400

Loa,

> level of "calling the consensus" that might be for the ADs.

As I said before, portions of the information (or sub-models) covered in
the document clearly are within the scope of a single WG (e.g., SR, LDP,
RSVP-TE ...).  The draft also has an overall model that ties all the
sub-models together.  I can't speak for other WGs, but I don't think
it's within scope of TEAS to work on this overall model.  My point about
the ADs is that the ADs can decide/change what is in scope for a
particular WG and therefore can direct where such work is discussed /
takes place.

> I was thinking about repeating the same discussion in more than one wg.
So we're agreement that this isn't a good idea.

> be on the able somewhere (at least on some table somewhere during the

In the long term, I suspect the document will morph into an overall
structure document with sub-models documented separately and by
different WGs.  In the short term, I certainly hope not to hear about
out of scope topics, e.g., LDP, in the TEAS discussion of the draft.

> will take this as a basis for discussing what will happen with the
I'm hoping for the former in TEAS, but if course my co-chair has a say
in this too.

Lou

---

From: "Osborne, Eric" <[email-masked]>
Date: Tue, 17 Mar 2015 16:17:06 +0000

...

> on this overall model.  My point about the ADs is that the ADs can
> decide/change what is in scope for a particular WG and therefore can direct
> where such work is discussed / takes place.

Normally I'd suggest taking the overall document to RTGWG and then announcing that parts will be covered in the appropriate WG, but RTGWG isn't until Thursday so the window will have closed by then.

Could we just get a good chunk of time (30min?) in RTGWG to cover all the drafts?  No matter what we do people are going to upset that things weren't discussed Their Favorite Way in Their Favorite WG, so can we aim to just minimize the number of cranky people?

eric

> 
> >>>> Does this make sense?
> >>> Makes sense to me. Just now we have a presentation on the MPLS
> >>> agenda, since time is the scarce thing during the IETF week, I don't
> >>> think we should present it more than in one place.
> >> Actually, I may disagree.  I do agree that having popup discussions
> >> on the same (overal structure) topic isn't too helpful.  But, I think
> > understand the formula "relevant piece of the to the relevant wg",
> > this is not what I see happening. What we have in the agendas posted
> > today is that mpls and teas have slots, but you say the draft (or
> > pieces of the draft) are relevant also at least to rtgwg, spring and
> > i2rs, and there are currently no agenda slots for that discussion in
> > those wg's, neither am I sure that splitting it up that much is most
> > productive.
> >
> > To discuss the home(s) of the document, I think the entire scope
> > should be on the able somewhere (at least on some table somewhere
> > during the week).
> 
> In the long term, I suspect the document will morph into an overall structure
> document with sub-models documented separately and by different WGs.
> In the short term, I certainly hope not to hear about out of scope topics, e.g.,
> LDP, in the TEAS discussion of the draft.
> 
> 
> > We could tell them "give us some context, but for the rest keep to
> > what is strictly relevant for MPLS" or we could say "give us some
> > context, discuss what is relevant for MPLS and also bring up what you
> > feel you has not had opportunity to discuss in any other wg during
> > week and we will take this as a basis for discussing what will happen
> > with the document on this list".
> I'm hoping for the former in TEAS, but if course my co-chair has a say in this
> too.
> 
> Lou
> >> chair) most of the time will be spent discussing the WG-related
> >> portion of the document that overlaps other individual documents that
> >> are also being discussed, and perhaps also how the in-WG scope models
> >> tie into other models.  IMO omitting this draft from our Dallas
> >> discussions would hurt WG progress on the topic.
> >>
> >> I'm not expecting to cover the out of scope portions of the draft in
> >> our TEAS meeting in Dallas, and interest in the overall structure
> >> discussion let me to start this thread.
> >>
> >> Lou
> >>> /Loa
> > <snip>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Mar 2015 16:35:13 +0000

Hi Eric, 

On 3/17/15, 12:17 PM, "Osborne, Eric" <[email-masked]> wrote:

>Normally I'd suggest taking the overall document to RTGWG and then
>announcing that parts will be covered in the appropriate WG, but RTGWG
>isn't until Thursday so the window will have closed by then.
>
>Could we just get a good chunk of time (30min?) in RTGWG to cover all the
>drafts? 

RTGWG agenda is already jam packed - no room for any additions. The
results of the Encap design team will be presented there which is taking
up a large slot but there are also a number of proposed YANG models.

Talk to you in the Big “D”,
Acee 

> No matter what we do people are going to upset that things weren't
>discussed Their Favorite Way in Their Favorite WG, so can we aim to just
>minimize the number of cranky people?
>
>
>
>
>
>eric
>
>
>> 
>> >>>> Does this make sense?
>>structure
>>in this

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Mar 2015 12:44:36 -0400

Hi Eric,

> Normally I'd suggest taking the overall document to RTGWG and then announcing that parts will be covered in the appropriate WG, but RTGWG isn't until Thursday so the window will have closed by then.
Discussing the overall aspect of document in RTWG, if there's time,
sounds reasonable to me. 

> Could we just get a good chunk of time (30min?) in RTGWG to cover all the drafts?  
There too many interrelated docs to cover in a single meeting, for
example we have 70 minutes of wg-specific yang discussions on the teas
agenda.

> No matter what we do people are going to upset that things weren't discussed Their Favorite Way in Their Favorite WG, so can we aim to just minimize the number of cranky people?

or coordinate as much as possible before hand (hay, perhaps on this
list) to get folks in sync before the meeting...

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Mar 2015 12:45:18 -0400

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.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Mar 2015 10:24:47 +0100

Folks,

I have not seen any reaction to this, what is the plan?

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Mar 2015 11:04:48 +0100

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.

/Loa

--

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Mar 2015 09:59:22 -0400

> 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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Mar 2015 15:12:38 +0100

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 [email-masked], possibly before,
  during and after the Dallas meeting."

I agree to that!

/Loa

--

---

From: Joshua George <[email-masked]>
Date: Mon, 16 Mar 2015 11:51:44 -0700

Hi Lou,

We've been nearly exclusively focused on the content and structure of the
draft so far, and haven't yet given a lot of thought to the administrative
component of it. Our initial thought was to present to both mpls and teas,
and then decide based on the feedback where to direct updates.

Thanks!

--josh

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 19 Mar 2015 15:07:34 +0000

Hi Josh,

You are (Eric?) also presenting in rtgwg :)

Cheers,
Jeff

From: Joshua George <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 16, 2015 at 10:51 AM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt

Hi Lou,

We've been nearly exclusively focused on the content and structure of the draft so far, and haven't yet given a lot of thought to the administrative component of it. Our initial thought was to present to both mpls and teas, and then decide based on the feedback where to direct updates.

However, we'd be grateful for any thoughts or suggestions you have on finding the right home for it. Please let us know.

Thanks!

--josh

On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Authors,

Nice bit of work here. It has a pretty comprehensive scope and touches a few wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize this work, what are your thoughts / plans on how you are going to break down the work into different pieces and WGs?

Thanks,
Lou

--- Forwarded message ---
From: [email-masked]<mailto:[email-masked]>
Date: March 9, 2015 6:49:56 PM
Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
To: <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Mar 2015 12:13:32 -0400

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.

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 19 Mar 2015 18:31:35 -0400

> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <[email-masked]> wrote:
> 
> Hi Lou and Loa,
> 
> 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

	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
> 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
> 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
> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson <[email-masked] <mailto:[email-masked]>> wrote:
> Lou,
> 
> I take this to mean:
>  need a discussion on the [email-masked] <mailto:[email-masked]>, possibly before,
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
> 
> 
> -- 
> 
> 
> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
> Huawei Technologies (consultant)     phone: +46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
>

---

From: Rob Shakir <[email-masked]>
Date: Fri, 20 Mar 2015 15:39:29 +0000

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

---

From: Rob Shakir <[email-masked]>
Date: Fri, 20 Mar 2015 15:47:50 +0000

Oh, and the other point that I would like to make on this (but got trigger happy with pressing send) — I’m not sure that anyone (I certainly wouldn’t) would claim that this draft, or the other more structural modules that we (openconfig) have published recently reflect a wholly completed items to be rubber-stamped. That is clearly not the intention and there are surely issues and concerns that have not even been considered at the moment… however, community feedback and review is the best way to get that thinking done — so I certainly would welcome feedback on them.

Some of the issues might be cross-working-group, but that’s sort of the point of this list - and the way we work on network _management_ might not end up looking exactly like the way that we work on network _protocols_. Let’s not constrain our thinking.

(Thanks to the ADs and rtgwg chairs for accommodating discussion in Dallas.)

r.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 20 Mar 2015 15:50:17 +0000

Our pleasure :)

Cheers,
Jeff

-----Original Message-----
From: Rob Shakir <[email-masked]>
Date: Friday, March 20, 2015 at 7:47 AM
To: "Thomas D. Nadeau" <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>, Alia Atlas
<[email-masked]>, Alia Atlas <[email-masked]>, Berger Lou
<[email-masked]>, Joshua George <[email-masked]>, Loa Andersson
<[email-masked]>
Subject: Re: [Rtg-yang-coord] I-D Action:
draft-openconfig-mpls-consolidated-model-00.txt

>Oh, and the other point that I would like to make on this (but got
>trigger happy with pressing send) ‹ I¹m not sure that anyone (I certainly
>wouldn¹t) would claim that this draft, or the other more structural
>modules that we (openconfig) have published recently reflect a wholly
>completed items to be rubber-stamped. That is clearly not the intention
>and there are surely issues and concerns that have not even been
>considered at the momentŠ however, community feedback and review is the
>best way to get that thinking done ‹ so I certainly would welcome
>feedback on them.
>
>Some of the issues might be cross-working-group, but that¹s sort of the
>point of this list - and the way we work on network _management_ might
>not end up looking exactly like the way that we work on network
>_protocols_. Let¹s not constrain our thinking.
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 20 Mar 2015 12:20:18 -0400

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

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.

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.

Regards,
Alia

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 20 Mar 2015 13:03:05 -0400

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

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

> Whether some of this work makes sense to do in a wiki or live as a stable RFC is a different question - but

	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.

	--Tom

> 
> Regards,
> Alia
> 
> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Lou and Loa,
>>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 20 Mar 2015 13:11:36 -0400

On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau <[email-masked]>
wrote:

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

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

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

Regards,
Alia

> --Tom
>
>
>
> Regards,
> Alia
>
> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <[email-masked]
> > wrote:
>
>>
>> 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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 20 Mar 2015 13:34:42 -0400

> On Mar 20, 2015:1:11 PM, at 1:11 PM, Alia Atlas <[email-masked]> wrote:
> 
> 
> 
> On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Tom,
>> 
> 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. 
> 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

> 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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 20 Mar 2015 13:45:33 -0400

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

> On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau <[email-masked]
> > wrote:
>
>>
> 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.

> 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 <
>> [email-masked]> wrote:
>>
>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 20 Mar 2015 14:30:11 -0400

Hi Tom,

I just created a place holder wiki for the DT -- to be filled in as work
spins up/progresses.
See http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT

Lou
On 3/20/2015 1:34 PM, Thomas D. Nadeau wrote:
> A wiki is quick and easy.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 20 Mar 2015 14:40:32 -0400

Thanks man. Thats a step in the right direction. 8)

> On Mar 20, 2015:2:30 PM, at 2:30 PM, Lou Berger <[email-masked]> wrote:
> 
> Hi Tom,
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 24 Mar 2015 09:35:50 -0500

BTW how does this effort work with this draft?

https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

> On Mar 20, 2015:1:40 PM, at 1:40 PM, Thomas D. Nadeau <[email-masked]> wrote:
>