liu.bin21 | 23 Jul 04:00 2014
Picon

Re: Reply to comments -- Comparison between FAR and OSPF - FRR


Hello Curtis,

Thank you for your comments.
But from what did you get conclusion of 'research projects'? We not only have a deployment experience but also strict large-scale system data analysis.

Following is my reply:

'No SPF is required for FRR to provide protection, restoring traffic flow though sometimes on a suboptimal path.'
--Is FRR only used within domain? If so, it can be counted as a drawback. And LDP FRR cannot guarantee that the calculated path is the optimal path, leading to the emergence of new link congestion. But FAT TREE architecture network is a non-blocking network.

'One commercial CSPF measured about a decade ago completed in 30-40msec on a test topology of 450.  That was on a 300 MHz or less PPC or Pentium-2.
Todays processors are an order of magnitude faster, so we could expect (with order NlogN scaling of SPF) to get about the same SPF time on a topology of 4K or more nodes with no improvements in software.'
--As seen from the above CSPF business application data, there is a linear correlation between the convergence time and the number of topologies, while it is not sensitive to the FAR.
To compare the FRR and FRR, the working process of the LDP FRR technology is described as follows:
1) Running LDP protocol in the network, it works as DU (downstream independent) label distribution + orderly label control + free label retention. (Disadvantage :additional protocol overhead)

In the above case, there are two paths from R1 to R5, R5 initiates multi-label mapping message to the upstream. Eventually, R2 and R3 respectively assign labels to R1 for reaching R5, among which, the label distributed by R2 is the primary label, the label distributed by R3 can be used as a backup. (Disadvantage: the irregular topology leads to complex routing and prone to cause more serious link block)

2) Specify one equipment port of the LSR as the backup of another equipment port.

3) Equipment maintenance label forwarding table: As the port backup has not been implemented, one label forwarding table has only one next hop and label, and the label is distributed for FEC by the LDP peer connected to the next hop of the routing of FEC. After the port backup is implemented, if the next hop of a label forwarding table is the protected port, add a next hop and label for the entry, and the label is distributed for FEC by the LDP peer connected to the backup next hop. (Disadvantage: large protocol database overhead and processing overhead)

4) Equipment maintenance of the working status of each port (normal/failure).

5) Packets reach the next hop, and are forwarded to the destination according to the corresponding label forwarding table.

It can be seen from the above FRR processing that FRR has the following disadvantages compared to FAR:

1) Additional protocol overhead: For the protection of links, nodes and paths, it is necessary to set up a backup LSP respectively, which causes unnecessary overhead and complex protocol processing; (there is no such protocol overhead for FAR, and because FAR is based on regular topology, path protection and switching process are simple.)

2) Backup LSP failures may exist. As there is no protection mechanism, it cannot fast reroute when it fails; (FatTree network architecture has multiple natural selection.)

3) There is a linear correlation between the convergence time and the number of topologies, while it is not sensitive to the FAR.

4) LDP FRR cannot guarantee that the calculated path is the optimal path, leading to the emergence of new link congestion. But FAT TREE architecture network is a non-blocking network.

Best.

Richard
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Jeff Tantsura | 9 Jul 19:11 2014
Picon

IETF 90 RTGWG Agenda

Hi RTGWG:

The agenda for IETF 90 RTGWG has been posted:
https://datatracker.ietf.org/meeting/90/agenda/rtgwg

Looking forward to seeing you in Toronto!

Cheers,
Jeff
internet-drafts | 4 Jul 19:36 2014
Picon

I-D Action: draft-ietf-rtgwg-mrt-frr-architecture-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees
        Authors         : Alia Atlas
                          Robert Kebler
                          Chris Bowers
                          Gabor Sandor Enyedi
                          Andras Csaszar
                          Jeff Tantsura
                          Maciek Konstantynowicz
                          Russ White
	Filename        : draft-ietf-rtgwg-mrt-frr-architecture-04.txt
	Pages           : 41
	Date            : 2014-07-04

Abstract:
   With increasing deployment of Loop-Free Alternates (LFA) [RFC5286],
   it is clear that a complete solution for IP and LDP Fast-Reroute is
   required.  This specification provides that solution.  IP/LDP Fast-
   Reroute with Maximally Redundant Trees (MRT-FRR) is a technology that
   gives link-protection and node-protection with 100% coverage in any
   network topology that is still connected after the failure.

   MRT removes all need to engineer for coverage.  MRT is also extremely
   computationally efficient.  For any router in the network, the MRT
   computation is less than the LFA computation for a node with three or
   more neighbors.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-04

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/
liu.bin21 | 2 Jul 11:20 2014
Picon

Requests time slot for FAR <at> IETF 90 rtgwg


Greeting all,

We wish to present our new version draft(draft-sl-rtgwg-far-dcn-01) during this  
meeting, consequently, we would like to ask for a time slot for the draft presentation.

-topic: Generic Fault-avoidance Routing Protocol for Data Center Networks
-URL:   http://www.ietf.org/internet-drafts/draft-sl-rtgwg-far-dcn-01.txt
- brief statement of problem & updateing for comments.
- requested duration: 15min
- speaker name: Bhumip Khasnabish

I'll appreciate the opportunity of time slot. We hope to receive guidance and agreement from the chairs and the experts.

Many thanks for guidance, and best wishes.

Regards.

Yours Sincerely,

Richard bin liu
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alvaro Retana (aretana | 27 Jun 22:48 2014
Picon

IETF 90 Agenda Items (rtgwg)

Hi!

We have a 90-minute slot in Toronto on Wednesday afternoon:
WEDNESDAY, July 23, 2014 1520-1650 Afternoon Session II Ballroom RTG rtgwg Routing Area Working Group WG
Send any requests for time to Jeff and I.  We will prioritize the items already listed in the charter as milestones. Other items may be considered if we have time.

Please note that we will be requiring two conditions to be part of the final agenda: (1) your draft MUST have been published already, and (2) you MUST provide the chairs with your slides by EOD on Monday, July 21, 2014.  We will also appreciate starting a discussion on the list so everyone is aware of your draft and/or any updates.

Keep the following dates in mind:
Thanks!

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
stephane.litkowski | 27 Jun 14:26 2014

FW: New Version Notification for draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt

Hi RTGWGers, 

Here is a problem statement draft showing the impact of using different SPF strategies in link state IGP protocols.

Comments are welcome.

Stephane

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Friday, June 27, 2014 14:09
To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF
Subject: New Version Notification for draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt

A new version of I-D, draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt
has been successfully submitted by Stephane Litkowski and posted to the IETF repository.

Name:		draft-litkowski-rtgwg-spf-uloop-pb-statement
Revision:	00
Title:		Link State protocols SPF trigger and delay algorithm impact on IGP microloops
Document date:	2014-06-27
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt
Status:         https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-spf-uloop-pb-statement/
Htmlized:       http://tools.ietf.org/html/draft-litkowski-rtgwg-spf-uloop-pb-statement-00

Abstract:
   A micro-loop is a packet forwarding loop that may occur transiently
   among two or more routers in a hop-by-hop packet forwarding paradigm.

   In this document, we are trying to analyze the impact of using
   different Link State IGP implementations in a single network in
   regards of microloops.  The analysis is focused on the SPF triggers
   and SPF delay algorithm in a first step.

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.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne
doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur,
veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant
susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be
protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
internet-drafts | 24 Jun 21:30 2014
Picon

I-D Action: draft-ietf-rtgwg-rlfa-node-protection-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Remote-LFA Node Protection and Manageability
        Authors         : Pushpasis Sarkar
                          Hannes Gredler
                          Shraddha Hegde
                          Chris Bowers
                          Stephane Litkowski
                          Harish Raghuveer
	Filename        : draft-ietf-rtgwg-rlfa-node-protection-00.txt
	Pages           : 16
	Date            : 2014-06-24

Abstract:
   The loop-free alternates computed following the current Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
   protection.  The resulting Remote-LFA nexthops (also called PQ-
   nodes), may not gaurantee node-protection for all destinations being
   protected by it.

   This document describes procedures for determining if a given PQ-node
   provides node-protection for a specific destination or not.  The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-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/
Pushpasis Sarkar | 24 Jun 10:37 2014
Picon

FW: New Version Notification for draft-psarkar-rtgwg-rlfa-node-protection-05.txt

Hi All,

We have addressed all of the pending comments in the latest version of this draft. Request you all to review
and provide feedback. 

Also we would like to re-call for WG adoption for this draft and take it forward as a WG document (as was
decided in last IETF meeting).

Thanks and Regards,
-Pushpasis

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Tuesday, June 24, 2014 1:59 PM
To: Shraddha Hegde; Harish Raghuveer; Shraddha Hegde; Hannes Gredler; Harish Raghuveer; Stephane
Litkowski; Chris Bowers; Pushpasis Sarkar; Chris Bowers; Pushpasis Sarkar; Hannes Gredler; Stephane Litkowski
Subject: New Version Notification for draft-psarkar-rtgwg-rlfa-node-protection-05.txt

A new version of I-D, draft-psarkar-rtgwg-rlfa-node-protection-05.txt
has been successfully submitted by Pushpasis Sarkar and posted to the IETF repository.

Name:		draft-psarkar-rtgwg-rlfa-node-protection
Revision:	05
Title:		Remote-LFA Node Protection and Manageability
Document date:	2014-06-24
Group:		rtgwg
Pages:		16
URL:            http://www.ietf.org/internet-drafts/draft-psarkar-rtgwg-rlfa-node-protection-05.txt
Status:         https://datatracker.ietf.org/doc/draft-psarkar-rtgwg-rlfa-node-protection/
Htmlized:       http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-psarkar-rtgwg-rlfa-node-protection-05

Abstract:
   The loop-free alternates computed following the current Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
   protection.  The resulting Remote-LFA nexthops (also called PQ-
   nodes), may not gaurantee node-protection for all destinations being
   protected by it.

   This document describes procedures for determining if a given PQ-node
   provides node-protection for a specific destination or not.  The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints.

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.

The IETF Secretariat
Fan, Peng | 20 Jun 10:43 2014
Picon

Fwd: New Version Notification for draft-fan-sunset4-router-id-00.txt

Hi all,

The following draft is about problems of managing router IDs in an
IPv6 only network as well as some solution ideas. There was a good
discussion of this in IDR in last meeting, and this draft is an effort
based on the feedback collected. It is posted to sunset4, and I feel
it may also be interesting in rtgwg as the IDs are commonly used in
routing protocols.

Your review and comments are appreciated.

Best regards,
Peng

---------- Forwarded message ----------
From: internet-drafts <at> ietf.org
Date: Fri, 20 Jun 2014 00:50:46 -0700
Subject: New Version Notification for draft-fan-sunset4-router-id-00.txt
To: Peng Fan <fanp08 <at> gmail.com>

A new version of I-D, draft-fan-sunset4-router-id-00.txt
has been successfully submitted by Peng Fan and posted to the
IETF repository.

Name:		draft-fan-sunset4-router-id
Revision:	00
Title:		Managing Router Identifiers during IPv4 Sunset
Document date:	2014-06-20
Group:		Individual Submission
Pages:		3
URL:
http://www.ietf.org/internet-drafts/draft-fan-sunset4-router-id-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fan-sunset4-router-id/
Htmlized:       http://tools.ietf.org/html/draft-fan-sunset4-router-id-00

Abstract:
   This document describes problems of managing protocol identifiers
   when turning off IPv4 and migrating to IPv6 only network, with some
   potential solutions discussed.

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.

The IETF Secretariat
Peter Psenak | 11 Jun 10:06 2014
Picon

Re: 答复: Re: Reply to comments -- Comparison between FAR and OSPF

Richard,

On 6/11/14 06:11 , liu.bin21 <at> zte.com.cn wrote:
> Peter:
> 
> "the arguments you use against existing IGPs would be valid 20 years 
> ago, but not today."
> No matter in which year the arguments are referenced, the difference is 
> significant, which is determined by two different design concepts.

that is not a valid argument. The fact that there is a difference does
not mean anything, unless the difference itself makes an impact.

> 
> "First, links have high bandwidth, CPUs are fast and any serious IGP 
> implementation has addressed the bottlenecks you are talking about."
> As the number of nodes increases and the high bandwidth is required, the 
> number of protocol packets which are transmitted and needed to be 
> processed is growing exponentially. But the CPU of a switch can only 
> process a few hundred packets per second; therefore, the processing 
> capacity of the CPU limits the increase of the number of nodes. I have 
> tried to adjust the processing capacity of the CPU in the actual 
> commercial systems, the processing capacity may be increased to 
> thousands packets per second in some way, but at the expense of other 
> protocol processing performance. Therefore, in the large-scale FAT TREE 
> system, the processing capacity of the CPU in those commercial systems 
> cannot cope with a large number of OSPF protocol packets.
> 
> 'These days IGPs can support thousands of nodes in an area without any 
> problem, and converge sub-second, with precomputed backups, even withing 
> few tens of miliseconds.'
> For thousands of nodes, it is still a small scale. Once it comes up to 
> tens of thousands of nodes, IGP will not do the job.

above is an academic statement.

First, you need to provide a real world scenario where tens of thousands
of nodes need to be deployed in a flat area. Secondly you need to
describe why the current IGPs would not be able to do the job or be
improved to do it.

> 
> 'There are real deployments that clearly prove it, it's not an academic 
> statement.'
> I have developed and implemented a lot of routing and switching 
> commercial systems. These issues are not academic statements, but the 
> real lessons.
> 
> 'Even the periodic flooding can be avoided completely using RFC 4136.'
> RFC 4136 is only applicable to medium-sized networks. In terms of tens 
> of thousands of nodes in the data centers nowadays, it cannot do the job.
> 
> We need to be open-minded to adapt to the increasing scales of data 
> centers.

being open minded is fine. Defining a new protocol requires more then
just being open minded, otherwise we would have hundreds of routing
protocols defined already.

thanks,
Peter

> 
> Regards,
> 
> Richard Bin Liu
> 
> 
> 
> *Peter Psenak <ppsenak <at> cisco.com>*
> 
> 2014/05/15 14:41
> 
> 	
> 收件人
> 	liu.bin21 <at> zte.com.cn, Hannes Gredler <hannes <at> juniper.net>, "Alvaro 
> Retana (aretana)" <aretana <at> cisco.com>,
> 抄送
> 	adrian <at> olddog.co.uk, ytsun <ytsun <at> bjtu.edu.cn>, 
> rtgwg-chairs <at> tools.ietf.org, rtgwg <at> ietf.org
> 主题
> 	Re: Reply to comments -- Comparison between FAR and OSPF
> 
> 
> 	
> 
> 
> 
> 
> 
> Liu,
> 
> the arguments you use against existing IGPs would be valid 20 years ago,
> but not today. First, links have high bandwidth, CPUs are fast and any
> serious IGP implementation has addressed the bottlenecks you are talking
> about. These days IGPs can support thousands of nodes in an area without
> any problem, and converge sub-second, with precomputed backups, even
> withing few tens of miliseconds. There are real deployments that clearly
> prove it, it's not an academic statement. Even the periodic flooding can
> be avoided completely using RFC 4136.
> 
> regards,
> Peter
> 
> 
> On 5/15/14 07:08 , liu.bin21 <at> zte.com.cn wrote:
>  >
>  > Greeting all:
>  >
>  > I read comments on our draft, thank you for your comments.
>  >
>  > And some questions had already been replied in our latest FAR
>  > presentation material(not been presented at the meeting because of
>  > hard-deadline):
>  >
>  > --------"Draft is highly subjective. Data Centers are using existing
>  > protocols without problems."
>  > Why OSPF and other conventional routing methods do not work well in a
>  > large-scale network with several thousands of routers?
>  > As everyone knows, the OSPF protocol uses multiple databases, more
>  > topological exchange information (as seen in the following example) and
>  > complicated algorithm. It requires routers to consume more memory and
>  > CPU processing capability. But the processing rate of CPU on the
>  > protocol message per second is very limited. When the network expands,
>  > CPU will quickly approach its processing limits, and at this time OSPF
>  > can not continue to expand the scale of the management. The SPF
>  > algorithm itself does not thoroughly solve these problems.
>  >
>  > On the contrary, FAR does not have the convergence time delay and the
>  > additional CPU overheads, which SPF requires. Because in the initial
>  > stage, FAR already knows the regular information of the whole network
>  > topology and does not need to periodically do SPF operation.
>  >
>  > One of the examples of "more topological exchange information":
>  > In the OSPF protocol, LSA floods every 1800 seconds. Especially in the
>  > larger network, the occupation of CPU and band bandwidth will soon reach
>  > the router’s performance bottleneck.
>  > In order to reduce these adverse effects, OSPF introduced the concept of
>  > Area, which still has not solved the problem thoroughly). By dividing
>  > the OSPF Area into several areas, the routers in the same area do not
>  > need to know the topological details outside their area. (In comparison
>  > with FAR, after  OSPF introducing the concept of Area, the equivalent
>  > paths cannot be selected in the whole network scope)
>  >
>  >   OSPF can achieve the following results by Area :
>  > 1) Routers only need to maintain the same link state databases as other
>  > routers within the same Area, without the necessity of maintaining the
>  > same link state database as all routers in the whole OSPF domain.
>  > 2) The reduction of the link state databases means dealing with
>  > relatively fewer LSA, which reduces the CPU consumption of routers;
>  > 3) The large number of LSAs flood only within the same Area.
>  > But, its negative effect is that the smaller number of routers which can
>  > be managed in each OSPF area.
>  > On the contrary, because FAR does not have the above disadvantages, FAR
>  > can also manage large-scale network even without dividing Areas.
>  >
>  > The aging time of OSPF is set in order to adapt to routing
>  > transformation and protocol message exchange happened frequently in the
>  > irregular topology. Its negative effect is:
>  > when the network does not change, the LSA needs to be refreshed every
>  > 1800 seconds to reset the aging time. In the regular topology, as the
>  > routings are fixed, it does not need the complex protocol message
>  > exchange and aging rules to reflect the routing changes, as long as LFA
>  > mechanism in the FAR is enough.
>  >
>  > Therefore, in FAR, we can omit many unnecessary processing and the
>  > packet exchange. The benefits are fast convergence speed and much larger
>  > network scale than other dynamic routing protocol.
>  > Now there are some successful implementations of simplified routings in
>  > the regular topology in the HPC environment.
>  > Conclusion:As FAR needs few routing entries and the topology is
>  > regular, the database does not need to be updated regularly. Without the
>  > need for aging, there is no need for CPU and bandwidth overhead brought
>  > by LSA flood every 30 minutes, so the expansion of the network has no
>  > obvious effect on the performance of FAR, which is contrary to OSPF.
>  >
>  > --------"Network convergence doesn't follow link state
>  >            dynamics - Fast reroute exists. "
>  >
>  > Comparison of convergence time:
>  > The settings of OSPF spf_delay and spf_hold_time can affect the change
>  > of convergence time. The convergence time of the network with 2480 nodes
>  > is about 15-20 seconds(as seen in the following pages); while the FAR
>  > does not need to calculate the SFP, so there is no such convergence time.
>  > These issues *still exist*in rapid convergence technology of OSPF and
>  > ISIS (such as I-SPF). The convergence speed and network scale constraint
>  > each other. FAR does not have the above problems, and the convergence
>  > time is almost negligible.
>  >
>  > And test data is been include in another pptx material named OSPF in
>  > DCN(2).pptx, which can be download from IETF.
>  >
>  > Looking forward to further discussion.
>  >
>  > Best.
>  >
>  > Richard Bin Liu
>  >
>  >
>  > _______________________________________________
>  > rtgwg mailing list
>  > rtgwg <at> ietf.org
>  > https://www.ietf.org/mailman/listinfo/rtgwg
>  >
> 
> 

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Jeff Tantsura | 10 Jun 23:03 2014
Picon

FW: Improving and Restructuring the Routing Area

Dear rtgwgers,

Please be aware of the ongoing effort to improve the IETF Routing Area , please also note that discussion will happen on routing-discussion <at> ietf.org.  
So if you want to participate then please join that list. 

Cheers,
Jeff


---------- Forwarded message ----------
From: Alia Atlas <akatlas <at> gmail.com>
Date: Tue, Jun 10, 2014 at 3:57 PM
Subject: Improving and Restructuring the Routing Area
To: routing-discussion <at> ietf.org


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
directorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release notes).

Second, as was discussed during the recent IESG retreat, 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 played
with safely), 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 routing-discussion <at> ietf.org about how to
   reorganize the working groups to best meet our motivations.
   Additional focused discussions are expected on the

   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 discussion 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) Move towards organizing working groups on functional
   responsibilities rather than scoping them to specific protocols.

   2) Split giant working groups so relevant work is done in one place
   and there is an improved signal-to-noise ratio for participants who
   are only interested in a slice of the current working group's work.

   3) Create synergies for scattered functionality (example ideas:
   OAM, FRR, traffic-engineering)

   4) Create a 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.

The goal of this reorganization is not closing working groups.  Adrian
and Alia are perfectly capable of closing working groups without going
through restructuring.

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,
Alia and Adrian


_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Gmane