Welcome to the Routing Area Wiki
This Wiki contains additional information for the Routing Area.
- Who are the Routing Area Directors?
- What is the Routing Area Responsible For?
- Routing Area Working Groups
- Routing Area Discussion List
- Routing Area Directorate
- Routing Area English Language Review Team
- Routing Area Design Teams
- Code Points, Internet-Drafts, and Early Implementation
- Routing Area Yang Modeling Coordination
- Routing Area Open Source Coordination
- Routing Area Directors' ADnits
- IETF High-Level Working Group Summaries
- Interim Meetings
- IETF Meeting Conflict Avoidance
Who are the Routing Area Directors?
- Alia Atlas akatlas+iesg@…
Alia is affiliated with Juniper Networks
Deborah is affiliated with AT&T
Alvaro is affiliated with Cisco
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 firstname.lastname@example.org|
|Routing Yang Architecture||charter and members updated||Mar 26, 2015, Updated Aug 19, 2016||Still Open||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|
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 Yang Modeling Coordination
The IETF Routing Area has begun work on YANG (RFC 6020) models for its routing protocols. Each Working Group is responsible for the creation of its own modules. Since YANG efforts within the IETF are new, the Routing Area Yang Coordinators Forum has been created to socialize the work, share tips on modeling and create re-usable shared components that can be leveraged by the various Working Groups.
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
Here is a blank summary to seed for future IETFs.
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.