Subject: Re: [RTG-DIR] Plan for reorganizing the Routing Area

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Tue, 3 Jun 2014 13:07:51 +0000

Adrian, all

My 2euro cents 

 I wonder if one of the first questions isn't about the charter of the routing area itself. For instance its first sentence refers to "continuous operation of the routing system" while OPS states its technical areas cover "routing operations" but presently only BGP/Global routing in GROW and multicast in MBONED have an OPS WG.

 More generally, a split/reorganization can realized in different ways: protocol design - protocol operation split vs. per-protocol split (from architecture to operations) vs. domain split (xVPN, traffic-engineering, unicast IP routing, multicast routing, etc.). 

 In order to determine which one(s) would better suite, the motivations might require further work. From the 6 points, three appear as motivations (why): create synergies, accommodate new ideas and relevant work, decrease signal-to-noise ratio, the three others 1) 5) 6) are related to the question on how the reorganization would be guided and what it would imply it terms of work for each WG.

Thanks,
-dimitri.

> -----Original Message-----
> From: rtg-dir [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, May 31, 2014 3:22 PM
> To: 'Alexander Vainshtein'
> Cc: [email-masked]; 'Alia Atlas'
> Subject: Re: [RTG-DIR] Plan for reorganizing the Routing Area
> 
> Hello Sasha,
> 
> > A few naïve questions if you do not mind:
> 
> I don't think a question can be naive.
> 
> > 1. How do I subscribe to the  [email-masked] list?
> 
> https://www.ietf.org/mailman/listinfo/routing-discussion
> 
> > 2. Your email mentions splitting some "giant" WGs. Could you provide a
> > couple of specific examples of the WGs you consider giant? IMO this
> > would be most helpful for effective discussion, since I suspect that a
> > giant WG could be very different for different people.
> 
> Weeeeeeell, yes I could, and I do have some things in mind. But I would
> prefer for this to be a more open discussion and get ideas and opinions
> from the area rather than stamp my views on you all.
> 
> > 3. For the sake of curiosity, do you consider also conclusion of some
> > WGs as part of the re-organization? The email does not mention that.
> 
> Yes, it probably should mention this as a possibility, and everything is
> on the table. But, again, I'd like to hear opinions. Maybe work should be
> grouped together resulting in one new WG in place of two old ones. Maybe
> something is coming to its natural end or has run out of steam. Discuss...
> 
> > 4. Do you expect the RTG-DIR reviews you mention as part of the WG
> > Draft QA process to be in addition to or instead of the RTG-DIR
> > reviews as they are done today (i.e., during the IESG Last Call)?
> > IMHO and FWIW it should be an addition, with different RTG-DIR members
> > doing these reviews, because adding a fresh pair of eyes looking at
> > the draft is quite valuable; but I do not know whether this is feasible
> .
> 
> Good question.  What do others think? Should we continue to review during
> IETF last call as well as at WG adoption and WG last call? Should it be
> the same reviewer all the way through, or a different reviewer at
> different times?
> 
> > 5. Creating synergies for scattered functionalities is very important;
> > however, I believe that this cannot be provided by just reorganization
> > of the WGs. Just thinking aloud - maybe we need a process that would
> > identify cross-WG items early and effectively handle them in a cross-
> > WG manner all the way?
> 
> Yes, I'd like to explore that idea and see what processes we would need
> and how this might work.
> 
> > My 2c,
> 
> And welcomed.
> 
> Adrian

---

From: Lou Berger <[email-masked]>
Date: Sun, 08 Jun 2014 21:10:40 -0400

Alia, Adrian,
   
Sorry about being slow to respond.  A couple of largely unrelated points
to consider as part of this exercise:

A) There seems to be tension between doing the "quick & simple" vs doing
something that is more "common & generic".   I think there is a tricky
line to walk, and getting the balance right is not easy.  Focusing too
much on the former is very satisfying from a milestone perspective, but
it can result in many different solutions/implementations that are
essentially aimed at variations of the same problem.  Of course focusing
to much on the latter can lead to never having anything defined (I just
saw a WG in another area give up a problem because, IMO, they were too
focused on this.)  I think it will be interesting to consider,  directly
discuss, and document this tension as part of the WG reorg.

- As part of the training, it might be useful to have some material
covering what is minimally/really needed in a PS to ensure interoperable
implementations.  I think this is more of an issue for (new, and
sometimes not) authors than chairs, but if the chairs & rtg-dir have
this in hand it could be really helpful.  (I have my standard list that
I seem to always be bringing up to authors, others probably have theirs
too and combining such might be really helpful.)

Lou

On 5/30/2014 3:53 PM, Alia Atlas wrote:
> To all the Routing WG Chairs & Routing Directorate Members:
>
> Enclosed is an email that we intend to send to
> [email-masked] <mailto:[email-masked]> on
> Monday June 9.
>
> As you may recall, Adrian and I asked how to improve getting work done
> in the area.  After discussion, we think that includes working group
> reorganization.  
>
> We depend very heavily upon you to come up with solid proposals for
> the reorganized WGs and their suggested WG chairs.
>
> Thanks,
> Alia & Adrian
>
>
> =============================
>
> To all participants in the Routing Area,
>
> Adrian and I are working on improving the quality, speed, and
> experience of getting work done in the IETF Routing Area.  There are
> three initiatives that we are working: WG Draft QA, Routing Area
> specific WG chair training, and reorganizing the working groups in the
> area.
>
> First, we intend to use our Routing Directorate more proactively by
> introducing a Working Group Draft Quality Assurance (WG Draft QA)
> process where the same selected routing directorate member will review
> a draft during WG draft adoption and during WG last call.  The process
> will be documented on the Routing Area wiki.  This should allow
> directorate reviews to report technical issues that can actually get
> fixed early in the process (equiv of bug reports) as opposed to just
> noting the concerns in the drafts (equiv of release notes).
>
> Second, in addition to the IETF-wide WG chair training, we intend to
> have a series of training sessions for WG Chairs in the Routing Area
> addressing topics such as judging consensus, project management,
> motivating volunteers, using the datatracker (via a sandbox version
> that can be safely played with), and sharing experiences between WG
> chairs.
>
> Third, we intend to reorganize the working groups in the Routing area.
> We feel that it is important to focus on areas where there is active
> interest in standardization and to be open and able to accept new work
> into the area.  As you know, we have had several new working groups
> (nvo3, i2rs, sfc, spring) created in the last few years and we need to
> be open and able to handle more new work as it comes in.  We would
> also like to improve the signal-to-noise ratio experienced by
> participants in the different working groups and improve the quantity
> and quality of discussion and reviews.  It is likely that not all WGs
> in the Routing Area will be directly affected.
>
> Here is the time-line for reorganizing the WGs.
>
>    NOW: public discussion on [email-masked]
> <mailto:[email-masked]> about how to
>    reorganize the working groups to best meet our motivations.
>    Additional focused discussions are expected on the
>    [email-masked] <mailto:[email-masked]> and
> [email-masked] <mailto:[email-masked]> mailing lists.
>
>    In Toronto: There will be meetings with the WG chairs and the
>    Routing Directorate to get the ideas described and agreed upon.
>
>    At the Routing Area Meeting in Toronto: Discuss the set of
>    reorganized WGs and general charter content in the Routing Area
>    meeting.
>
>    September 2014: Based upon the feedback, suggestions, and
>    discussion, Adrian and I finalize the reorganized WG charters.  We
>    start the internal IESG and public reviews.
>
>    October 2014: Formal rechartering process completes.
>
>    In Honolulu: The new set of WGs meet.
>
>    After Honolulu: Adrian and I deal with any issues and charter
>    updates based upon a few months of experience.
>
> Here are the motivations that Adrian and I would like to be considered
> when coming up with ideas for how the WGs should be reorganized.
>
>    1) Towards functional organization instead of just protocol
>
>    2) Split giant working groups so relevant work done together with
>    improved signal-to-noise ratio for participants
>
>    3) Create synergies for scattered functionality (example ideas:
>    OAM, FRR, traffic-engineering)
>
>    4) DISPATCH working group for clear new idea discussion; rtgwg
>    serves some of this purpose but doesn't have a clear process and
>    isn't drawing in the new ideas.
>
>    5) Focus Routing Area time on design centers rather than on far
>    corner cases.
>
>    6) Each working group should have clear, well defined, and
> achievable goals.
>
> Noting that the Routing Area has inherited some of its WG structure
> from the sub-IP area, it is not a goal to force IP routing and MPLS
> routing to remain separated.
>
> For those of you that have read this far, thank you.  Getting this 80%
> right is going to take some serious discussion and thought.  We all
> work in the Routing Area together with different perspectives.  Please
> think carefully and help us have a highly focused discussion.
>
> Thanks,

---

From: "Russ White" <[email-masked]>
Date: Mon, 9 Jun 2014 06:59:39 -0400

Y'all:

I know this is a really old email, but I'm sometimes just that far behind. :-(

> We feel that it is important to focus on areas where there is active interest in
> standardization and to be open and able to accept new work into the area.
> As you know, we have had several new working groups (nvo3, i2rs, sfc,
> spring) created in the last few years and we need to be open and able to
> handle more new work as it comes in.  We would also like to improve the
> signal-to-noise ratio experienced by participants in the different working
> groups and improve the quantity and quality of discussion and reviews.  It is
> likely that not all WGs in the Routing Area will be directly affected.

It occurred to me that it might be useful to split specific work from more general work by building a "two tier" structure of some sort here. What if we made design teams a normal part of business and the smallest component of work, rather than the working group? What I'm thinking is a process something like this:

- New work is always proposed on a rtg area wide (either rtg-area or rtg-wg) mailing list
- Once momentum is behind that new work (meaning we get to a -01 of a use cases or requirements draft), then a design team is formed on the mailing list for this work
- At the time the design team is formed, it's also assigned to a "mother ship" protocol level (or otherwise) working group 
- The design team has a specific charter, much like a task specific working group, with timelines, suggested output, etc., and a mailing list
- As the design team progresses, it has regular presentations and reports into the working group it's tethered to
- Primary review falls on the design team member, second level on the working group, third level on the directorate, etc.
- If the work succeeds, then the drafts are (eventually) tossed in as working group documents

I think part of the problem is that we have working group confusion -- I2RS is about gathering requirements, and determining if we need a protocol, OSPF is about OSPF, SIDR is about modifying the protocol of another working group, etc. Some WG's are formed based on a perceived need, others are formed based on working on a specific protocol in a more general way -- this means we have a mish mash of various things going on in different places. 

Converting the WG role into more of an advisor of design teams would provide one more level of review, the ability for people to work on more specific projects they want to work on (and leaving others to focus on the overall protocol going forward). The process of discussing the idea in the routing area wide first would give us more focus in thinking about new working groups, and the design team process would allow us to (potentially) commit less time and resources to new work until it's had a little time to bake, and to see better whether work will actually progress into a new protocol (which means a new WG), be restricted to a single protocol, or be something that applies to multiple protocols (which probably means a new WG, but some work could live forever as a design team under the rtg-wg).

This might be "too much structure," or it might help us sort the difference between functions and protocols in some better way (?).

:-)

Russ

---

From: Lou Berger <[email-masked]>
Date: Mon, 09 Jun 2014 10:09:44 -0400

Russ,
    What you describe has been informally repeated in ccamp for each new
technology/major extension that has been proposed.  One of the patterns
that has reoccurred along with it is that the set of authors involved
(the informal/self organized design team) come up with a solution that 
fully addresses their requirements, but does so without regard for
future common reuse and often miss  existing protocol mechanisms.   The
challenge with this is that the authors believe they have a fully baked
solution ready for RFC and now the WG needs to convince them to make
changes in their 'perceived perfectly adequate' solution to avoid
duplication of mechanisms in the same protocol (for slightly different
applications).

I do like your idea of formalizing this process as part of the
solution.  If the above took place as WG design team, rather than as
'individual' work, the chairs could ensure early
participation/review/contribution from those in the WG who have border
understanding. The likelihood of needing to do major changes once the
design team completed should be lower than what we've seen in  the
past.  (BTW my personal approach in trying to address this problem is to
get work adopted as WG drafts when they are less mature, but I've been
surprised that this has met with some resistance -- perhaps the design
team approach would be more acceptable to some.)  

Lou