Subject: FW: Routing Area organization

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Jun 2014 14:04:49 +0100

Forwarding with Joel's permission.
 
From: Joel Halpern [mailto:[email-masked]] 
Sent: 23 June 2014 17:14
To: Alia Atlas; [email-masked]
Subject: Routing Area organization
 
(Feel free to circulate this if you think it is useful.  I don't have the right
email addresses on this machine to send directly to the relevant parties.)
 
In looking at the discussion of the routing area, it seems to me that the
starting premise is very important.  I believe we all agree that we want a
structure that helps us produce useful RFCs to enable a stronger and more
innovative routing system that meets the real needs of the various kinds of
operations to deliver Internet services.  (I.e the general IETF goals.)
The following are my rough thoughts on this topic, as input to the discussion.
 
First, I take it as given that there may well be a better way to structure the
work.  The structure we have is an outgrowth of years of accumulation.  It seems
to me distinctly worth looking at whether looking at what changes we can make,
what they will accomplish,a nd if any of them are likely to improve our working.
Personally, I think this examination is long overdue.  Note that even if we
decide that we like the current structure, it will still have been worth looking
and understanding why we are working the way we are.
 
One of the biggest problems I see is the number of times when work has to be
presented in multiple working groups, and the drafts revised to address related
but disconnected concerns.  This waste author energy and working group time.
This is a consequence of our feeling a need to control how protocols evolve.
And such control is necessary.  But needs to be balanced with other needs.
Also we all become tourists very often even in working groups we are interested
in.
 
Any arrangement of work other than treating the world as one working group
(which I hope we all agree would be a very bad idea) will need some
cross-communciation between groups.  But some arrangements produce better
commonality.  Similarly, any arrangement will produce working groups where some
of the work is of less interest to some of the participants.  But maybe we can
get better alignment?
 
A couple of obvious examples.  Anything that needs to be done in an IGP needs to
be done twice (fortunately, we no longer care about RIP.)  Different working
groups all need to develop operations, adminsitration, and maintenance
mechanisms.  But that means they need to redevelop the common understanding of
what the needs, known techniques, and hard questions are.
 
So I think we would benefit from rearranging the deck chairs.  I would try to
make the groups focus on external needs rather than on mechanism.
 
I would start by merging the OSPF and ISIS working groups.  
I would also pull the OAM functions out of the various groups (BFD, MPLS, CCAMP,
.) and create one place that can deal with OAM issues.
I would probably then merge SPRING with core MPLS functioning.
We have just closed KARP, and I would (unhappily, but I think necessarily) close
ForCES.
I would either close ROLLand move the work into a common low power group in
another area, or make ti the common low power working group.
I would merge IDR and SIDR.  With the current SIDR work program, it no longer
makes sense to me to treat them as separate.
I would look at merging L2vpn and l3vpn back together.  And combining them with
NVO3.  Probably also include PWE3 in that set, although that is a harder call
and may be too different.
 
I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would fit
well with other groups.
 
Yours,
Joel

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 24 Jun 2014 13:24:06 +0000

No mention of MANET in Joel's analysis.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: routing-discussion [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 24 June 2014 14:05
To: [email-masked]
Subject: FW: Routing Area organization

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Forwarding with Joel's permission.

From: Joel Halpern [mailto:[email-masked]]
Sent: 23 June 2014 17:14
To: Alia Atlas; [email-masked]<mailto:[email-masked]>
Subject: Routing Area organization

(Feel free to circulate this if you think it is useful.  I don't have the right email addresses on this machine to send directly to the relevant parties.)

In looking at the discussion of the routing area, it seems to me that the starting premise is very important.  I believe we all agree that we want a structure that helps us produce useful RFCs to enable a stronger and more innovative routing system that meets the real needs of the various kinds of operations to deliver Internet services.  (I.e the general IETF goals.)
The following are my rough thoughts on this topic, as input to the discussion.

First, I take it as given that there may well be a better way to structure the work.  The structure we have is an outgrowth of years of accumulation.  It seems to me distinctly worth looking at whether looking at what changes we can make, what they will accomplish,a nd if any of them are likely to improve our working.  Personally, I think this examination is long overdue.  Note that even if we decide that we like the current structure, it will still have been worth looking and understanding why we are working the way we are.

One of the biggest problems I see is the number of times when work has to be presented in multiple working groups, and the drafts revised to address related but disconnected concerns.  This waste author energy and working group time.  This is a consequence of our feeling a need to control how protocols evolve.  And such control is necessary.  But needs to be balanced with other needs.   Also we all become tourists very often even in working groups we are interested in.

Any arrangement of work other than treating the world as one working group (which I hope we all agree would be a very bad idea) will need some cross-communciation between groups.  But some arrangements produce better commonality.  Similarly, any arrangement will produce working groups where some of the work is of less interest to some of the participants.  But maybe we can get better alignment?

A couple of obvious examples.  Anything that needs to be done in an IGP needs to be done twice (fortunately, we no longer care about RIP.)  Different working groups all need to develop operations, adminsitration, and maintenance mechanisms.  But that means they need to redevelop the common understanding of what the needs, known techniques, and hard questions are.

So I think we would benefit from rearranging the deck chairs.  I would try to make the groups focus on external needs rather than on mechanism.

I would start by merging the OSPF and ISIS working groups.
I would also pull the OAM functions out of the various groups (BFD, MPLS, CCAMP, ...) and create one place that can deal with OAM issues.
I would probably then merge SPRING with core MPLS functioning.
We have just closed KARP, and I would (unhappily, but I think necessarily) close ForCES.
I would either close ROLLand move the work into a common low power group in another area, or make ti the common low power working group.
I would merge IDR and SIDR.  With the current SIDR work program, it no longer makes sense to me to treat them as separate.
I would look at merging L2vpn and l3vpn back together.  And combining them with NVO3.  Probably also include PWE3 in that set, although that is a harder call and may be too different.

I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would fit well with other groups.

Yours,
Joel

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Jun 2014 09:34:17 -0400

While I chartered MANAT a long time ago, I don't really know enough 
about what is it doing.  SO I could not, in good faith explicitly 
recommend closure, merging with low power, or leaving along.

Yours,
Joel

On 6/24/14, 9:24 AM, Dearlove, Christopher (UK) wrote:
> No mention of MANET in Joel’s analysis.
>
> --
>
> Christopher Dearlove
>
> [email-masked] <mailto:[email-masked]> |
> http://www.baesystems.com
>
> *From:*routing-discussion [mailto:[email-masked]]
> *On Behalf Of *Adrian Farrel
> *Sent:* 24 June 2014 14:05
> *To:* [email-masked]
> *Subject:* FW: Routing Area organization
>
> **** WARNING ****
>
> /This message originates from outside our organisation, either from an
> external partner or the internet.//
> /Consider carefully whether you should click on any links, open any
> attachments or reply./
> /For information regarding //*/Red Flags/*/that you can look out for in
> emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.//
> /If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.//
>
> *From:*Joel Halpern [mailto:[email-masked]]
> *Sent:* 23 June 2014 17:14
> *To:* Alia Atlas; [email-masked] <mailto:[email-masked]>
> *Subject:* Routing Area organization
>
> (Feel free to circulate this if you think it is useful.  I don't have
> the right email addresses on this machine to send directly to the
> relevant parties.)
>
> In looking at the discussion of the routing area, it seems to me that
> the starting premise is very important.  I believe we all agree that we
> want a structure that helps us produce useful RFCs to enable a stronger
> and more innovative routing system that meets the real needs of the
> various kinds of operations to deliver Internet services.  (I.e the
> general IETF goals.)
>
> First, I take it as given that there may well be a better way to
> structure the work.  The structure we have is an outgrowth of years of
> accumulation.  It seems to me distinctly worth looking at whether
> looking at what changes we can make, what they will accomplish,a nd if
> any of them are likely to improve our working.  Personally, I think this
> examination is long overdue.  Note that even if we decide that we like
> the current structure, it will still have been worth looking and
> understanding why we are working the way we are.
>
> One of the biggest problems I see is the number of times when work has
> to be presented in multiple working groups, and the drafts revised to
> address related but disconnected concerns.  This waste author energy and
> working group time.  This is a consequence of our feeling a need to
> control how protocols evolve.  And such control is necessary.  But needs
> to be balanced with other needs.   Also we all become tourists very
> often even in working groups we are interested in.
>
> Any arrangement of work other than treating the world as one working
> group (which I hope we all agree would be a very bad idea) will need
> some cross-communciation between groups. But some arrangements produce
> better commonality.  Similarly, any arrangement will produce working
> groups where some of the work is of less interest to some of the
> participants.  But maybe we can get better alignment?
>
> A couple of obvious examples.  Anything that needs to be done in an IGP
> needs to be done twice (fortunately, we no longer care about RIP.)
> Different working groups all need to develop operations, adminsitration,
> and maintenance mechanisms.  But that means they need to redevelop the
> common understanding of what the needs, known techniques, and hard
> questions are.
>
> So I think we would benefit from rearranging the deck chairs.  I would
> try to make the groups focus on external needs rather than on mechanism.
>
> I would also pull the OAM functions out of the various groups (BFD,
> MPLS, CCAMP, …) and create one place that can deal with OAM issues.
>
> I would either close ROLLand move the work into a common low power group
> in another area, or make ti the common low power working group.
>
> I would merge IDR and SIDR.  With the current SIDR work program, it no
> longer makes sense to me to treat them as separate.
>
> I would look at merging L2vpn and l3vpn back together.  And combining
> them with NVO3.  Probably also include PWE3 in that set, although that
> is a harder call and may be too different.
>
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 24 Jun 2014 16:11:01 +0200

Joel,

and what would be your views on the remaining two: I2RS and SFC?

Also, except for OAM, you propose to merge groups. Do you think there 
are other elements existing in various working groups which we could 
aggregate to form a new WG, i.e. do a split and merge rather than a 
merge only.

-m

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jun 2014 11:54:10 +0100

> I would start by merging the OSPF and ISIS working groups.
I agree, although I would make this something like IGPmaint and give it 
the scope off all IGPs. I take this position becsue partially because 
there was a small issue that arose with RIP recently and there was no 
where to take it, and partially because I am not convinced we should 
write off DV protocols yet since they can do some quire interesting 
things. I might take MRT to this WG since it is a routing protocol.
> MPLS, CCAMP, ...) and create one place that can deal with OAM issues.
>
That works.
> I would probably then merge SPRING with core MPLS functioning.
I am not sure about this. IF SPRING reduced scope to MPLS that would 
work, but I do not see how you would do IPv6 in the MPLS WG, and it we 
split it we will end up with two forking designs.
> necessarily) close ForCES.
Agree
>
> I would either close ROLLand move the work into a common low power 
> group in another area, or make ti the common low power working group.
>
That makes sense.
> longer makes sense to me to treat them as separate.
I think that this makes sense in the long term (12 to 18months) but I am 
not sure that SIDR is down to the level of work where this would make 
sense yet.
> is a harder call and may be too different.
I tried the LxVPN merge and it was not popular, but now might be the 
time to try again. I don't think NVO3 belongs there since that will set 
the assumption of a L3VPN control plane and although the L3VPN part 
shoulr probbaly be moved to the LxVPN or at least the L3VPN WG
> would fit well with other groups.

Given that PWE3 is mainly LDP control plane and not much dataplane 
anymore, I would think about merging it into MPLS.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jun 2014 11:55:15 +0100

> and what would be your views on the remaining two: I2RS and SFC?
They probably need to continue on their own for a bit.

Stewart

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 25 Jun 2014 13:46:39 +0200

> They probably need to continue on their own for a bit.

Does this suggest that, in your opinion, only mature WG are subject to 
the reorganisation?

-m

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jun 2014 13:46:03 +0100

> Does this suggest that, in your opinion, only mature WG are subject to 
That depends! Certainly I would start that way.

The recent WGs were created by the consensus of the IETF and if it made 
sense to merge them with existing WGs that would have been considered at 
the time of creation. The starting point would therefore seem to be to 
consider the older WGs and then to see the shape of the area looked like 
before changing those that were recently created.

Stewart

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 26 Jun 2014 02:19:38 +0100

I don't agree mostly because the details/reasons for merge did not
including performance/production of each WG or related main routing RFC
standards. Comments below,

On Tuesday, June 24, 2014, Adrian Farrel wrote:

> *From:* Joel Halpern [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *To:* Alia Atlas; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> (Feel free to circulate this if you think it is useful.  I don't have the
> right email addresses on this machine to send directly to the relevant
> parties.)
>
>
>
> So our analysis need also to consider our useful RFCs or our main routing
standards that new RFCs develop from.  Any decision we make should look
into the current standards of this Area.

> First, I take it as given that there may well be a better way to structure
> the work.  The structure we have is an outgrowth of years of accumulation.
>
>
IMHO, the WG work structure has no problem, the problem is Area structure,
or Area Work. The topic is about the Area or inside the Area not inside the
WG.

>   It seems to me distinctly worth looking at whether looking at what
> changes we can make, what they will accomplish,a nd if any of them are
> likely to improve our working.  Personally, I think this examination is
> long overdue.  Note that even if we decide that we like the current
> structure, it will still have been worth looking and understanding why we
> are working the way we are.
>
> We are working the way we are because we follow ADs or IESG, and mostly we
concentrate on work within WG but leave Area work to ADs. Leaders are
responsible but followers may waste efforts.

>
>
> One of the biggest problems I see is the number of times when work has to
> be presented in multiple working groups, and the drafts revised to address
> related but disconnected concerns.  This waste author energy and working
> group time.  This is a consequence of our feeling a need to control how
> protocols evolve.  And such control is necessary.  But needs to be balanced
> with other needs.   Also we all become tourists very often even in working
> groups we are interested in.
>
>
Yes

> cross-communciation between groups.
>
> This can be done by DTs or WGs' chairs, as first, then when we get results
or recommendations we can do larger volumes.

> But some arrangements produce better commonality.  Similarly, any
> arrangement will produce working groups where some of the work is of less
> interest to some of the participants.  But maybe we can get better
> alignment?
>
> We cannot depend on probabilities, and we need known agreements of future
arrangements.

> I think IESG should push for that redevelop strategy for all Areas.

>
>
> So I think we would benefit from rearranging the deck chairs.  I would try
> to make the groups focus on external needs rather than on mechanism.
>
> Please don't ignore that our IETF process structure WGs, so who approved
charters. I think let us think that we are the AD to rearrange the Area, so
what is Area manager focus before the Group manager? Then what is the
Group focus? The directors should focus first on the external needs, to
form progress, then groups will be more guided.

> I would also pull the OAM functions out of the various groups (BFD, MPLS,
> CCAMP, …) and create one place that can deal with OAM issues.
>
> I would look at merging L2vpn and l3vpn back together.  And combining them
> with NVO3.  Probably also include PWE3 in that set, although that is a
> harder call and may be too different.
>
>
>
> The above suggestions have not clarify reasons, but seem to help more
noise, more work for WG-Chair, less group-production, and less work for
ADs. What are the main standards and future developments? What are the
results of performance of those WGs?

AB

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jun 2014 11:12:05 -0400

> another area, or make ti the common low power working group.

ROLL will close by the end of 2014.  We thought that IETF90 might be the last
in-person meeting, but I can't promise that yet.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 28 Jun 2014 00:21:00 +0100

I think including this Area's current standards relating to its WG, as we
don't forget about current standards. I noticed that there were pushing for
ROLL close but not sure if there was consensus in the WG to close. I
remember that there was serious discussions related to RPL performance, and
RPL is the main standard but it still may have issues.

So if there is community agreement to close ROLL, who will
consider developing RPL for more use cases. I have no problem with closing
this WG if ADs want, but we should not be closing develop standards or
leave their design not completed if some other want to continue.

AB

On Tuesday, June 24, 2014, Michael Richardson wrote:

>
> Adrian Farrel <[email-masked] <javascript:;>> wrote:
> group in
> Michael Richardson <[email-masked] <javascript:;>>, Sandelman
> Software Works

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sat, 28 Jun 2014 12:07:06 +0000

On the subject matter of ROLL, since I was co-chairing for 5 years, this seems premature to me. Indeed, there are now
several deployment with millions of nodes, and without a doubt protocol extensions will be required. Furthermore there
are true specifics about LLNs deserving IMO to keep the WG alive for some time at least.

Thanks.

JP.

On Jun 28, 2014, at 1:21 AM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

I think including this Area's current standards relating to its WG, as we don't forget about current standards. I noticed that there were pushing for ROLL close but not sure if there was consensus in the WG to close. I remember that there was serious discussions related to RPL performance, and RPL is the main standard but it still may have issues.

So if there is community agreement to close ROLL, who will consider developing RPL for more use cases. I have no problem with closing this WG if ADs want, but we should not be closing develop standards or leave their design not completed if some other want to continue.

AB

--
Michael Richardson <[email-masked]<javascript:;>>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

_______________________________________________
routing-discussion mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Jun 2014 18:29:24 +0100

Just for the record, Michael was quoting me quoting Joel. I did not say "I would
close ROLL".
 
On the other hand, work in the WG is tailing off as Michael says.
That says nothing about the success or failure of RPL, but rather that we have
reached something of a plateau in the standardisation.
When the WG has run out of work and assuming that there is no new work proposed
(by people who are actually doing the work!) then the WG would close.
Closing a WG is a mark of success, not failure.
Working groups are supposed to be set up to do something, do it, and then close.
 
It is quite possible that, at some time in the future, there will be a need to
do more work on RPL (adding any number of widgets, removing options, polishing
documentation) and that a new WG would be spun up to handle new work. That might
be next week or in ten years' time. 
 
Adrian

From: JP Vasseur (jvasseur) [mailto:[email-masked]] 
Sent: 28 June 2014 13:07
To: Michael Richardson; Adrian Farrel; Joel M. Halpern;
[email-masked]; Abdussalam Baryun
Subject: Re: Routing Area organization
 
On the subject matter of ROLL, since I was co-chairing for 5 years, this seems
premature to me. Indeed, there are now 
several deployment with millions of nodes, and without a doubt protocol
extensions will be required. Furthermore there 
are true specifics about LLNs deserving IMO to keep the WG alive for some time
at least.
 
Thanks.
 
JP.
 
On Jun 28, 2014, at 1:21 AM, Abdussalam Baryun <[email-masked]>
wrote:

I think including this Area's current standards relating to its WG, as we don't
forget about current standards. I noticed that there were pushing for ROLL close
but not sure if there was consensus in the WG to close. I remember that there
was serious discussions related to RPL performance, and RPL is the main standard
but it still may have issues.  
 
So if there is community agreement to close ROLL, who will consider developing
RPL for more use cases. I have no problem with closing this WG if ADs want, but
we should not be closing develop standards or leave their design not completed
if some other want to continue. 
 
AB

    > I would either close ROLLand move the work into a common low power group
in

--
Michael Richardson <[email-masked] <javascript:;> >, Sandelman Software
Works

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 29 Jun 2014 11:24:02 +0100

I think the most important missing item (to organise the area
by functionality and quality) is the routing-area-WG (rtgwg), which I
suggest should be closed, because it is a general interest and not
specific, not community-grouped, and does not ensure quality. How can an
area become a working group or a WG becoming an Area? IMHO, this rtgwg WG
is making the routing area not organised in terms of new-work/new-interest
approved by the area.

Routing Area WG helps close all other WGs because this WG is open chartered
as any area's purpose.

AB

On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote:

> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');> |

---

From: Loa Andersson <[email-masked]>
Date: Sun, 29 Jun 2014 13:44:04 +0200

Folks,

I'm not able to parse either of the paragraphs below, however let me
state that I think that the rtgwg is extremely useful, functions well
and have done a lot of high quality work.

/Loa

On 2014-06-29 12:24, Abdussalam Baryun wrote:
> area become a working group or a WG becoming an Area? IMHO,
> this rtgwg WG is making the routing area not organised in terms of
> new-work/new-interest approved by the area.
>
> Routing Area WG helps close all other WGs because this WG is open
> chartered as any area's purpose.
>
> AB
>
>     No mention of MANET in Joel’s analysis.____
>
>     __ __
>
>     -- ____
>
>     Christopher Dearlove____
>
>     Tel: +44 1245 242194 |  Fax: +44 1245 242124____
>

-- 

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

---

From: Martin Vigoureux <[email-masked]>
Date: Sun, 29 Jun 2014 16:01:46 +0200

> before changing those that were recently created.
One could argue that at the time of their creation the question of 
reorganizing the area was not on the table.
I am not advocating for considering all WGs, but on the other hand I do 
think that the age of a WG might not be the best criteria for selecting 
it, or not. More precisely if the plan is to reorganize the area we 
should be careful not to leave on the side few islands which would 
sustain the model that we seek to change. At the very least we should 
have a clear plan on how to integrate the for-further-study WGs.

-m

---

From: Rob Shakir <[email-masked]>
Date: Sun, 29 Jun 2014 12:56:23 +0100

Abdussalam,

Like Loa, I’m not too clear on the point that you are making here. Perhaps you can clarify for us?

rtgwg does a valuable job of picking up items that are not necessarily protocol specific, but require standardisation. The work on composite links, and IP FRR are good examples of this. In addition - it provides the hugely valuable roles of allowing operational considerations for wider routing issues to be considered, as well as the introduction and evaluation of new ideas, without a significant process overhead, which may subsequently be added to an existing WG’s charter, or result in a new WG being formed.

I would strongly oppose closing rtgwg.

Cheers,
r.

On 29 Jun 2014, at 11:24, Abdussalam Baryun <[email-masked]> wrote:

> I think the most important missing item (to organise the area by functionality and quality) is the routing-area-WG (rtgwg), which I suggest should be closed, because it is a general interest and not specific, not community-grouped, and does not ensure quality. How can an area become a working group or a WG becoming an Area? IMHO, this rtgwg WG is making the routing area not organised in terms of new-work/new-interest approved by the area.
> 
> Routing Area WG helps close all other WGs because this WG is open chartered as any area's purpose. 
> 
> AB
> 
> [email-masked] | http://www.baesystems.com
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Jun 2014 11:49:54 +0000

I also think RTGWG is very useful working group.
Since I see it can handle new work as follows:

-          Developing the new work related to routing area but not belong to any existing working groups

-          Developing a proposal for a BOF.

-          Developing a charter and establishing consensus for a new WG
Would it be good for rtgwg to help

-          Direct the work to an existing WG.
as well? Just like OPS Area has opsawg working group and RAI area has dispatch working group.

Regards!
-Qin
发件人: routing-discussion [mailto:[email-masked]] 代表 Rob Shakir
发送时间: 2014年6月29日 19:56
收件人: Abdussalam Baryun
抄送: [email-masked]; [email-masked]
主题: Re: Routing Area organization

Abdussalam,

Cheers,
r.

On 29 Jun 2014, at 11:24, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

AB

[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');> | http://www.baesystems.com<http://www.baesystems.com/>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 30 Jun 2014 14:32:26 +0100

Hi Qin and Rob,

Please don't misunderstand me, I am trying to discuss improving the area
organisation, I was not discussing improving WG organisation, because as I
said before all our WG have no problems and they are doing well. Please
read the point number 4 from first restructure-statements of Alia and
Adrian, I think the ADs agree to replace rtgwg WG with another more
functional in process so that we can have more clear charters as well.

AB

On Monday, June 30, 2014, Qin Wu wrote:

> *发件人:* routing-discussion [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *代表
> *Rob Shakir
> *发送时间:* 2014年6月29日 19:56
> *收件人:* Abdussalam Baryun
> *抄送:* [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *主题:* Re: Routing Area organization
>
>
>
> Abdussalam,
>
>
>
> rtgwg does a valuable job of picking up items that are not necessarily
> protocol specific, but require standardisation. The work on composite
> links, and IP FRR are good examples of this. In addition - it provides the
> hugely valuable roles of allowing operational considerations for wider
> routing issues to be considered, as well as the introduction and evaluation
> of new ideas, without a significant process overhead, which may
> subsequently be added to an existing WG’s charter, or result in a new WG
> being formed.
>
>
>
> On 29 Jun 2014, at 11:24, Abdussalam Baryun <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 30 Jun 2014 14:53:12 +0100

Hi Rob,

My point was to make our area work more clear and ensure quality. Is there
another way to handle the routing area's new work issues? Is the only
solution is having a WG to solve that as rtgwg? I was thinking of a
different solution than having a general purpose WG, but a DT.

I thought what is important to solve new standards process in the area is
not a General WG problem but it is a DT problem. So we use list for DT
or the same rtgwg list for discussing all new work
unrelated-to-area-current-WGs coming in the Routing Area. The new work
after DT approves becomes an individual area work.

Just my thoughts and trying to improve the organisation. I maybe wrong.

AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 30 Jun 2014 14:16:30 +0000

Rob,

The point I took from the email is that it's difficult to tell what the rtgwg is supposed to do (at least from the name). Calling it the "Routing Area Working Group" seems less like a name, and more like throwing IETF keywords against the wall until a sufficient number of them stick together. ;-)
I admit, I don't have a proposal here, although if one is necessary, we could borrow your text and call it the "Picking up items that are not necessarily protocol specific, but require standardization" Working Group. One obvious downside would be the length of the spiffy group-name acronym, I guess. ;-)

One other thing from your email caught my attention, and I was wondering if I could get some clarification. You state the WG is partially for "...as well as the introduction and evaluation of new ideas…". Isn't the introduction and evaluation of new work part of *all* of the working groups? Or (and this is addressed to the ADs), has something changed that we all need to be aware of?

Regards,
Stan

On Jun 30, 2014, at 9:53 AM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Rob,

My point was to make our area work more clear and ensure quality. Is there another way to handle the routing area's new work issues? Is the only solution is having a WG to solve that as rtgwg? I was thinking of a different solution than having a general purpose WG, but a DT.

I thought what is important to solve new standards process in the area is not a General WG problem but it is a DT problem. So we use list for DT or the same rtgwg list for discussing all new work unrelated-to-area-current-WGs coming in the Routing Area. The new work after DT approves becomes an individual area work.

AB

Cheers,
r.

On 29 Jun 2014, at 11:24, Abdussalam Baryun <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

AB

[email-masked] | http://www.baesystems.com<http://www.baesystems.com/>

[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Rob Shakir <[email-masked]>
Date: Mon, 30 Jun 2014 15:28:47 +0100

Hi Stan,

I agree, maybe a re-branding could be required. :-) 

> One other thing from your email caught my attention, and I was wondering if I could get some clarification. You state the WG is partially for "...as well as the introduction and evaluation of new i…

Of course, I guess I meant things that don’t clearly fit within the other working groups. If I have a new BGP idea, of course this would go to IDR. However, I think the value is that rtgwg allows other ideas (for example, SPRING, MRT, IP FRR) which might have cross-WG impact or maybe don’t look like they require a whole new WG to be introduced to an audience which includes a number of cross-routing area experts.

Does this make sense? :-)

r.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jun 2014 10:44:10 -0400

Following the lead of RAI< we could call it Routing Dispatcher instead 
of RTGWG, if that would help folks understand it better.

Yours,
Joel

On 6/30/14, 10:16 AM, Stan Ratliff (sratliff) wrote:
> Rob,
>
> The point I took from the email is that it's difficult to tell what the
> rtgwg is supposed to do (at least from the name). Calling it the
> "Routing Area Working Group" seems less like a name, and more like
> throwing IETF keywords against the wall until a sufficient number of
> them stick together. ;-)
> I admit, I don't have a proposal here, although if one is necessary, we
> could borrow your text and call it the "Picking up items that are not
> necessarily protocol specific, but require standardization" Working
> Group. One obvious downside would be the length of the spiffy group-name
> acronym, I guess. ;-)
>
> One other thing from your email caught my attention, and I was wondering
> if I could get some clarification. You state the WG is partially for
> "...as well as the introduction and evaluation of new ideas…". Isn't the
> introduction and evaluation of new work part of *all* of the working
> groups? Or (and this is addressed to the ADs), has something changed
> that we all need to be aware of?
>
> Regards,
> Stan
>
>
> On Jun 30, 2014, at 9:53 AM, Abdussalam Baryun
> <[email-masked] <mailto:[email-masked]>>
>   wrote:
>
>> Hi Rob,
>>
>> My point was to make our area work more clear and ensure quality. Is
>> there another way to handle the routing area's new work issues? Is the
>> only solution is having a WG to solve that as rtgwg? I was thinking of
>> a different solution than having a general purpose WG, but a DT.
>>
>> I thought what is important to solve new standards process in the area
>> is not a General WG problem but it is a DT problem. So we use list
>> for DT or the same rtgwg list for discussing all new work
>>     rtgwg does a valuable job of picking up items that are not
>>     necessarily protocol specific, but require standardisation. The
>>     work on composite links, and IP FRR are good examples of this. In
>>     addition - it provides the hugely valuable roles of allowing
>>     operational considerations for wider routing issues to be
>>     considered, as well as the introduction and evaluation of new
>>     ideas, without a significant process overhead, which may
>>     subsequently be added to an existing WG’s charter, or result in a
>>     new WG being formed.
>>
>>>     by functionality and quality) is the routing-area-WG (rtgwg),
>>>     which I suggest should be closed, because it is a general
>>>     interest and not specific, not community-grouped, and does not
>>>     ensure quality. How can an area become a working group or a WG
>>>     becoming an Area? IMHO, this rtgwg WG is making the routing area
>>>     not organised in terms of new-work/new-interest approved by the
>>>     area.
>>>
>>>         <http://www.baesystems.com/>
>>>
>>>         Registered Office: Warwick House, PO Box 87, Farnborough
>>>         Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
>> [email-masked] <mailto:[email-masked]>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 30 Jun 2014 14:57:26 +0000

Rob, 

> Does this make sense? :-)

That absolutely makes sense, and I agree. However, it does bring up an opportunity for me to crawl up on the old, rickety soapbox, and discuss something that bothers me about the routing area, and the IETF in general: 

I'm absolutely in agreement that we need ways to support and foster innovation. That said, I think we're organized into too many silos, with work that is 90% overlapping occurring in different working groups. The best example I can provide for that is ROLL and MANET. We had a lengthy discussion on the MANET list not that long ago on the topic "When is a low-power, radio-based, ad-hoc forming network *not* a MANET? The answer was: Basically, when it's a ROLL network." Another example along the same vein is the "ITS" working group that is trying to form in the Internet Area - they are concerned with putting networking gear into vehicles, forming "on-the-move", ad-hoc routing relationships, and opportunistically getting the best out of the network. However, instead of doing that work in ROLL (they are relatively low-power, radio-based, after all) or in MANET (did I mention ad-hoc? ;-) groups, the IETF is seeing fit to create yet another WG. 

This is all just IMHO, but it seems to me that this has more to do with politics (both inter-personal and inter-company), and less to do with technology. And I can't help but think that in the end, we will wind up with a plethora of solutions that won't interoperate. There might be job security in that we'll need a whole additional layer of RFCs to "glue" things together (e.g. - a RPL to OLSRv2 interoperability spec comes to mind), but that approach gives me the willies. Again, we need to foster innovation, but avoid re-addressing what is basically the same set of issues over and over again, coming up with "standard silos".

…easing my rather large fanny off of the soapbox for now… 

Regards,
Stan

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jun 2014 16:34:46 +0000

I like Joel's suggestions. There are indeed a lot of similarities among L2VPN/L3VPN/NVO3
The draft-ietf-nvo3-framework (that just pasted IETF last call) depicted the similar framework as L2VPN, except NV03 focusing on using IP as outer header whereas L2VPN having MPLS as outer header.

Besides consolidating the current WGs, hope the Routing area can start some new initiatives that are different from existing mode of operations.
As the industry is moving more towards open source, it can improve IETF's impact to industry by having a WG to promote Proof of Concept projects that engage multiple vendors and service providers. The Proof of Concept project code can be the baseline protocol specification.

By doing so, not only it promotes more collaboration among vendors/service providers, it also helps improving the image of IETF being too slow image..

My two cents,

Linda

From: routing-discussion [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, June 24, 2014 8:05 AM
To: [email-masked]
Subject: FW: Routing Area organization

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 30 Jun 2014 17:33:04 +0000

I agree with most of these suggestions, which align work more functionally rather than per protocol. I will also note that SPRING is not a contained subset of MPLS, as its charter says "  The initial data planes that will be considered are MPLS and IPv6."

A couple of additional observations:
* All these effectively reduce the number of WGs (by way of merging or closing). What is also interesting is a way to figure out how to kick off more work with agility, and RTGWG (or "Routing dispatch foobar WG") should not be a default gateway for everything else.
* If one of the motivations as laid out by Alia is to "split giant working groups" to focus work, there's a second phase missing and what is the target of more agile energy.
* Another area of interests is how to liaise work -- considering OAM as a function, much of the OAM generic work recently has come out of OPSAWG. I like OAM in routing as a function, but needs to be coordinated outside the RTG-Area too.
* Lastly, while WG reorg and scope is good, it should be only part of the exercise. A missing part is how to enable smaller "newer" WGs to deliver on its goals.

Thanks,

-- Carlos.

On Jun 25, 2014, at 6:54 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

I would start by merging the OSPF and ISIS working groups.
I agree, although I would make this something like IGPmaint and give it the scope off all IGPs. I take this position becsue partially because there was a small issue that arose with RIP recently and there was no where to take it, and partially because I am not convinced we should write off DV protocols yet since they can do some quire interesting things. I might take MRT to this WG since it is a routing protocol.
I would also pull the OAM functions out of the various groups (BFD, MPLS, CCAMP, …) and create one place that can deal with OAM issues.
That works.
I would probably then merge SPRING with core MPLS functioning.
I am not sure about this. IF SPRING reduced scope to MPLS that would work, but I do not see how you would do IPv6 in the MPLS WG, and it we split it we will end up with two forking designs.
We have just closed KARP, and I would (unhappily, but I think necessarily) close ForCES.
Agree
I would either close ROLLand move the work into a common low power group in another area, or make ti the common low power working group.
That makes sense.
I would merge IDR and SIDR.  With the current SIDR work program, it no longer makes sense to me to treat them as separate.
I think that this makes sense in the long term (12 to 18months) but I am not sure that SIDR is down to the level of work where this would make sense yet.
I would look at merging L2vpn and l3vpn back together.  And combining them with NVO3.  Probably also include PWE3 in that set, although that is a harder call and may be too different.
I tried the LxVPN merge and it was not popular, but now might be the time to try again. I don't think NVO3 belongs there since that will set the assumption of a L3VPN control plane and although the L3VPN part shoulr probbaly be moved to the LxVPN or at least the L3VPN WG

Given that PWE3 is mainly LDP control plane and not much dataplane anymore, I would think about merging it into MPLS.

- Stewart

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 30 Jun 2014 11:07:42 -0700

Linda,

It would be interesting to see how the IETF can better leverage open source
to achieve its goals. I am not sure that this discussion best starts with
"lets have a WG centered around it", but rather with questions whether
the IETF should consider open source as an actual official output - eg:
expand IETF beyond generating RFCs. 

Cheers
    Toerless

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 30 Jun 2014 21:23:50 +0100

>
>
> *From:* Joel Halpern [mailto:[email-masked]]
I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would
> fit well with other groups.
>
> I am not sure why to leave PIM alone. The PIM is a protocol focus group,
so it should be more functional focus, maybe focus on multicast functions.
Also other WG that focus on one protocol should consider discussing their
WG because usually the ones in protocol-WG are more aware to adapt to other
functions.

AB

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 30 Jun 2014 13:57:58 -0700

> so it should be more functional focus, maybe focus on multicast functions.

AFAIK, it already has that focus if you read the charter, eg:
in general it deals with all IP multicast routing/protocol issues, eg: for
example anything MAGMA was doing previously. Multicast things
are only done in other WGs when it is multicast+FOO and FOO-WG
feels they want to own it. Which in general is a good thing because
it help to ensure multicast+FOO becomes more mainstrain within FOO.

I may be wrong. Cc'ed the WG for further clarification.

The working group name has only been kept for historic fondness.

> WG because usually the ones in protocol-WG are more aware to adapt to other

Agreed. Functional grouping is certainly more desirable than protocol
centric WGs.

Cheers
    Toerless