This Wiki contains additional information for the Routing Area.
John is affiliated with Juniper Networks
Alvaro is affiliated with Futurewei Technologies
Andrew is affiliated with Liquid Labs
The Routing Area is responsible for facilitating the operation of the Internet routing system by maintaining and improving the scalability and stability characteristics of the existing routing protocols and developing new protocols, extensions, and bug fixes. Forwarding methods (such as destination-based unicast and multicast forwarding, MPLS, and pseudowire) as well as associated routing and signaling protocols (such as OSPF, IS-IS, BGP, RSVP-TE, LDP, PIM, RPL, and VPNs at Layer 2, Layer 3), and both centralized and distributed routing architectures (to address, for example, virtualization, service chaining, traffic engineering, and data center routing) are within the scope of the Routing Area. The interactions of routing systems with configuration and orchestration platforms (for example, routing-related YANG models and path computation engines) are handled in the routing area. The Routing Area also works on Generalized MPLS used in the control plane of optical networks and the security and manageability aspects of the routing system. The Routing Area Working Groups cover a wide range of data plane technologies (Layer 1, Layer 2, Layer 3) and control protocols.
List dedicated to general discussions of routing issues and topics relevant to the area: email@example.com
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.
There are some tools to help run your working group. Take a look and add your ideas.
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.
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:
There are also Guidelines for handling IANA Code Points in RTG Area Documents. Here is a link to the guidelines: CodePointGuidelines
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
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.
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.
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.
The content of this page was last updated on 2021-07-15. It was migrated from the old Trac wiki on 2022-12-20.