PRactically IDEal Working Group (PRIDE)

Current Status: Active Working Group

Chair(s): Theater style, facing projector screen

Routing Area Director(s): ADs will be routed using longest-delay-first algorithm

Responsible Area Director: Neither Alex nor Bill were considered responsible enough

Mailing Lists:

• General Discussion: in the spirit of this WG, any mailing list can be used
• To Subscribe: put your name at the end of your e-mail message
• In Subject: "Your eBay account"
• Archives: .zip, .arj, .tgz

Description of Working Group:

It has been widely recognized by the IETF community that achieving consensus on such protocol design details as packet formats or processing behavior is one of the most painful parts of the IETF process. While an agreement on these details is sometimes beneficial to the new market entrants who do not have adequate knowledge of the technology, it is blatantly clear to those versed in the routing art that restrictions of this type only get in the way of vendor differentiation and prevent the market from choosing the best technology. As another result, consumers of the technology, such as ISPs and enterprise networks, suffer from the limitations artificially imposed by strict information encoding and processing rules. It should be obvious to an informed reader that sufficient number of configuration parameters and moderate investment in reverse-engineering will satisfy any interoperability requirements.

The PRIDE WG is chartered to specify a new Internet forwarding behavior and a generalized routing protocol that would not suffer from the aforementioned disadvantages. At the time of WG creation, there was a clear consensus within the community that the solution should satisfy the following criteria:

1. IP forwarding. A number of concerns about the destination-based forwarding paradigm in IP have been brought up over the years. It is obvious that equipment from different vendors may be considerably faster if a method different from the 32-bit destination address lookup was used to determine the outbound interface. Possible examples include forwarding based on only the first 16 bits of the destination address, which could be suitable for the Internet core routers that don't need to know every subnet, or simply random selection of the next hop that requires no routing table maintenance or lookup operations. The solution produced by this WG will allow any algorithm to be used for IP packet delivery. The questions of interworking between different algorithms are considered outside the scope of the charter and are left for further study in the IETF OPS area and such forums as NANOG and RIPE.
2. Routing protocol: packet encapsulation. The long practice of encapsulating packets using a common transport protocol (TCP or UDP) or IP protocol number has proven to be unnecessarily restrictive. On top of the obvious inflexibility, this unfortunate limitation introduces additional security threats--publicly available IP protocol and TCP/UDP port numbers for the routing protocols make a targeted attack an easy task. Clearly, allowing the administrator to configure these parameters on a per-session basis or (better) change them in time, will substantially increase security of the network infrastructure. The protocol developed by this WG will allow the administrator to configure the encapsulation parameters. Advanced implementations are expected to simplify the configuration process by collecting statistical information and predicting correct encapsulation methods. Latest industry developments in pattern recognition make this practically feasible.
3. Routing protocol: information encoding. Experience with strict-format and TLV-based encoding has shown that flexibility in packet format is extremely useful for the protocol evolution. This WG will take the next step in this direction and will allow multiple encoding formats to be used between the protocol peers. The question of agreeing on the exact format between the sender and the receiver of the protocol messages is outside of the scope of this WG, however it is envisioned that this information maybe dynamically signalled, or statically configured by the administrator. Nevertheless, to achieve basic interoperability, the protocol encoding will be restricted so that the basic piece of the packet format is always an 8-bit integer, a.k.a. byte. Furthermore, to highlight the "Be liberal in what you receive and conservative in what you send" rule, receivers will be required to make as much sense as possible out of the received message, and senders will be restricted to using a single format per message.
4. Routing protocol: node-local behavior. For reasons unknown to the community, RTG ADs have been pushing WGs to specify certain aspects of node-local routing behavior, such as criteria for route calculation, best path determination, or routing update processing. This has been generally perceived as useless and counter-productive. It is an explicit non-goal of this WG to waste its time on describing such obviously implementation- specific aspects. It is painfully obvious to those adequately knowledgeable in routing that behavior of predominant implementations is in no way controlled by the protocol specification, and implementation of the so-called "standard" behavior by other vendors only diverts valuable resources from the reverse-engineering efforts.

This WG is officially relieved from the duty of specifying the MIB modules, documenting protocol analysis, and publishing implementation reports--Tom Nadeau will take care of the MIBs (and Bert) anyways; vendor marketing departments are much better at protocol analysis than the IETF; and implementation reports only reveal confidential marketing information.

Goals and Milestones:

Jul 05 Paris

Nov 05 Submit internet-draft on requirements for a framework document

May 06 Refresh requirements document

Jul 06 Should we go back to Paris?

Internet-Drafts:

• Guinness seems to be the preferred draft in the Internet routing community