Subject: WG Action: PRactically IDEal Working Group (pride)

From: Alex Zinin <[email-masked]>
Date: Fri, 1 Apr 2005 17:25:42 -0800

FYI below.
--
Alex
http://www.psg.com/~zinin

A new IETF working group has been formed in the Routing Area. For additional
information, please contact the Area Directors or the WG Chairs.

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

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion