Welcome to the Routing Area Wiki

This Wiki contains additional information for the Routing Area.

---

Who are the Routing Area Directors?

Deborah Brungard
​IESG biography
Deborah is affiliated with AT&T

Alvaro Retana aretana.ietf@…
​IESG biography
Alvaro is affiliated with Futurewei Technologies

Martin Vigoureux
​IESG biography
Martin is affiliated with Nokia

---

What is the Routing Area Responsible For?

See the summary of the Area Responsibilities ​Area Descriptions

---

Routing Area Working Groups

There is a list of the Routing Area working groups on the ​Datatracker Working Groups page. This page contains a link to each working group's datatracker page and also identifies the chairs of the working groups.

There are also ​Tools Pages from the Routing Area working groups. These pages also include lots of other useful information such as an SVN repository, ticketing systems, and a wiki per working group.

There are some tools to help run your working group. Take a look and add your ideas.

For WG Chairs (WG secretaries welcome), there is a set of WG chair training and also Routing Area WG Chair chats. The recordings and slides for completed WG chair training can be found here along with the schedule of upcoming calls.

RTG Area Working group wiki pages WorkingGroupPages

---

Routing Area Discussion List

There is an email list dedicated to general discussions of routing issues and topics relevant to the area. More details at ​the mailing list page

The idea of additional technical-interest based mailing lists to facilitate cross-WG discussion is being discussed at IETF90. Ideas for such mailing lists are found here.

---

Routing Area Directorate

The Routing Area Directorate is a groups of people with wide experience in designing, implementing, and operating IETF routing protocols. They help the ADs with document reviews and discussions about issues related to routing.

The Routing Area Directorate also contributes to the Document QA process.

See more information on the Routing Area Directorate charter page.

---

Routing Area English Language Review Team

This experimental team of volunteers exists to provide advice and document reviews with an emphasis on readability and English usage. Volunteers are always welcome, and any document author can approach the team to ask for help.

Look here for more information.

---

Routing Area Design Teams

Occasionally, it is useful to create a short-lived area-wide Design Team to focus on a topic that needs rapid, focused progress and covers topics that fall within the charters of multiple Working Groups. The work done by such Design Teams can then be discussed in a forum subject to a transparent, consensus-process such as a Working Group.

The following are the Routing Area Design Teams:

Design Team Name	Charter	Chartered	Closed	Wiki	Mailing List Archive
Dataplane Encapsulation Considerations	​charter and members	Dec 9, 2015	May 28, 2015	no wiki	​Archives for rtg-dt-encap-considerations@ietf.org
Routing Yang Architecture	​charter and members ​updated	Mar 26, 2015, Updated Aug 19, 2016	March 20, 2018	wiki	private archive for rtg-dt-yang-arch at ietf.org
Overlay OAM	​charter and members	Dec 16, 2015	July 21, 2016 ​closing email	wiki	​rtg-ooam-dt
Routing Security	charter and members	April 13, 2018	March 4, 2021		private archive

Code Points, Internet-Drafts, and Early Implementation

Early implementation of IETF protocols is encouraged with the understanding that Internet-Drafts are work in progress and may change at any time according to IETF consensus. Early implementation, especially that which involves interoperability testing, may need code points to be selected and it is generally agreed that documenting these code points is beneficial for stability of implementations and to avoid clashing with code point values needed for other Internet-Drafts.

Where an Internet-Draft defines a new registry it is safe for the document to include absolute numbers. However, where an Internet-Draft requires the allocation of new values from an existing registry it is important that the document does not state values until those values have actually been assigned by IANA since to do otherwise risks two documents claiming the same code points for different uses and two implementations clashing in the field.

Fortunately, code points can be allocated quite simply in most cases either by using Expert Review (if it applies to the registry) or by requesting Early Allocation as described in RFC 7120. All authors are strongly encouraged to use this approach, and Working Group chairs are asked to discourage the use of absolute values in Internet-Drafts unless those values come from new registries or have been assigned by IANA.

Thus, the process might go as follows:

• Individual I-D
• Preliminary implementation
• Adopted as working group I-D
• Further development of implementation
• Draft stabilizes
• Apply for early allocation using RFC 7120
• Code points assigned
• Interop testing and early deployments
• Work on I-D completes
• Working group last call
• IETF last call
• IESG approval
• RFC published
• IANA confirms code points for RFC

There are also Guidelines for handling IANA Code Points in RTG Area Documents. Here is a link to the guidelines CodePointGuidelines

---

Routing Area Open Source Coordination

For those working on or interested in Open Source related to work done in the Routing Area, there is a Routing Area Open Source Forum to share tips and information on the related projects. This will complement the rtg-open-source@… mailing list.

---

Routing Area Directors' ADnits

These are issues and concerns that are often raised by the Routing ADs during AD review when publication of an I-D as an RFC is requested, or that have been observed to be raised by other ADs during IESG review.

They are presented here to help authors get their documents approved more quickly.

Here is a presentation given to the MPLS working group at IETF-89 on this subject ​PowerPoint slides

And here is a link to a wiki page for the nits themselves RtgADNits

---

IETF High-Level Working Group Summaries

For IETF 93 and beyond, we want to have the WG Status that is reported in the rtgarea meeting be put into this Routing Area Wiki instead. By doing this, it is easy for WG Chairs to update the summaries at any time during the meeting. The ​Operations and Management Area wiki contains such summaries, such as for ​IETF 92.

• IETF 93 WG High Level Summaries
• IETF 94 WG High Level Summaries
• IETF 95 WG High Level Summaries
• IETF 96 WG High Level Summaries
• IETF 97 WG High Level Summaries
• IETF 98 WG High Level Summaries
• IETF 99 WG High Level Summaries
• IETF 100 WG High Level Summaries
• IETF 101 WG High Level Summaries
• IETF 102 WG High Level Summaries
• IETF 103 WG Summaries

Here is a blank summary to seed for future IETFs.

Interim Meetings

Physical (face-to-face) and virtual (such as using WebEx) meetings are a great way to achieve focused progress on working group topics. There is a small amount of process involved, but this is not very heavy.

Here is a page that explains more.

---

IETF Meeting Conflict Avoidance

As the number of working groups in the Routing Area grows it is becoming important to finely tune conflict avoidance: which WG meetings absolutely must not be scheduled at the same time.

Historically, the conflicts list given to the Secretariat is taken from the previous meeting with a trail back into the dawn of time. The conflicts can be archaic and irrelevant but serve to make the scheduling even harder.

Sometimes these conflicts are issues for one or two people and flagging them up can push things around so that other (unreported) conflicts show up. So some forethought is helpful.

We have an experimental conflict avoidance page where we will try to work out our conflicts in a little more detail in good time before the next IETF meeting.

---