IETF STEERING GROUP (IESG) REPORT FROM THE TELECONFERENCE SEPTEMBER 12TH, 1991 Reported by: Greg Vaudreuil, IESG Secretary This report contains - Meeting Agenda - Meeting Attendees - Meeting Notes Please contact IESG Secretary Greg Vaudreuil (iesg-secretary@nri.reston.va.us) for more details on any particular topic. Meeting Attendees ----------------- Borman, David / CRAY Callon, Ross / DEC Chiappa, Noel Crocker, Dave / DEC Coya, Steve / CNRI Davin, Chuck / MIT Gross, Philip / ANS Hobby, Russ / UC-DAVIS Hinden, Robert / BBN Vaudreuil, Greg / CNRI Regrets Almquist, Philip / Consultant Crocker, Steve / TIS Estrada, Susan / CERFnet Reynolds, Joyce / ISI Stockman, Bernard / SUNET/NORDUnet Agenda ------ 1) Administrivia - Bash the Agenda - Review of the Minutes - July 30th - Aug 2nd. (Pending Gross's review) - August 8th (Pending Gross's review) - August 15th (Pending Gross review) - August 29 (pending Gross review) - September 5 - Open Plenary - Meeting Schedule - Bi-monthly meetings> - Special topics meetings? - Schedule next meeting 2) Protocol Actions (See Appendix for recommendations) - Multi-protocol Interconnect over Frame Relay - Inverse ARP - IGP Applicability Statement 3) Technical Management - Routing Architecture discussion (Noel) - Routing Criterion Document Minutes ------- 1) Administrivia 1.1 Bash the Agenda The X500 protocol recommendations were deferred until next week so that Ross Callon could participate. 1.2. Approval of the Minutes No action was taken on the large set of non-approved minutes. The IESG is still waiting for Phill Gross's editorial comments. Minutes for September 5th were not available for review. 1.3. Bi-weekly meetings The IESG has been meeting weekly for many months now. This aggressive schedule was begun to reduce the backlog of actions in the beginning of this year. To reduce the time demands on area directors and the IETF Secretariat, the IESG will reduce it's meeting rate to every other week. 1.4 Schedule Next Meeting The next teleconference was scheduled for September 19th, and a second teleconference was scheduled for October 3rd. 2.1. Multi-protocol over Frame Relay The IESG requested the author of the multi-protocol interconnect document to change the emphasis of the document to IP over Frame Relay. The IESG requested this change in deference to what it saw as IAB desire to limit the scope of the document to IP issues and to avoid usurping the authority of other standards bodies to make standards for Frame Relay. The working group chairman and the author of the document reacted strongly to this change in emphasis arguing that liaison with the relevant standards bodies has occurred and the issues raised by the IAB have been addressed in the document as it was submitted. # # 45 minutes worth of stuff on IESG-IAB Interaction Pen-Up'ed # In resulting dialogue, it became clear to the IESG that the Working Group has addressed the concerns of the IAB to the extent they were expressed in response to the IESG's heads-up message. ACTION: Vaudreuil -- Modify the Multi-Protocol Interconnect recommendation to address the concerns of the IAB in respect to liaison activities of the Working Group and ANSI. Work with George Clapp to get the wording, and send to IAB when finished. 2.2 Inverse ARP The IESG reviewed the latest version of the Inverse ARP document and was not satisfied with the new working of the rational section. To resolve this editorial matter, Noel Chiappa was tasked to work directly with the author to craft appropriate wording. ACTION: Noel Chiappa -- Work with the author of the Inverse ARP specification to write up the wording for the rational section. ACTION: Greg Vaudreuil -- Send the IESG recommendation immediately after posting of the Inverse ARP document as an Internet Draft. 3.3 Routing Criterion The ``IESG Recommendation for Interior Gateway Protocols'' has been up for review in the internet-drafts directory for over a month, and is ready to be sent to the IAB. ACTION: Vaudreuil -- Send the recommendation to publish the IGP statement as an Applicability Statement. 3. Technical Management Issues 3.1 Routing Architecture Discussion The folks working on the Inter Domain Policy Routing protocols have expressed a desire to publish their work as a proposed standard. This work is very interesting and deserves wider exposure and implementation. Chiappa raised the question of whether the current routing architecture supported the deployment of this protocol into the wider internet. Specifically, the routing architecture of the Internet was not designed with multiple exterior gateway protocols, as is evidenced by the stress in the transition from EGP to BGP. The routing architecture of the Internet needs to change. There are many reasons including address depletion and routing table size that are likely to cause the current architecture to collapse. It is not clear if IDPR is the next step in the evolution of the architecture, and a commitment to this protocol as the next EGP is not wise at this time. The IDPR people recognize that IDPR is not yet ready to become the next EGP, but they do want to standardize the protocol and begin to gain the implementation and operational experience with the protocol normally associated with the standards track. They are ready for IDPR to become a "real" protocol. The Internet does allow for multiple standard protocols, especially where they can operate independently. IDPR does have the constituency and appears to have the maturity to become a proposed standard based on Hinden's criterion for standardizing routing protocols. The question for the IESG is whether the IDPR protocol and the other EGP's can in fact work independently. Chiappa described the following possible "states". 1) IDPR is an experiment but it is not "real". 2) IDPR is the best long term solution and migration should begin as soon as possible. 3) There may be 2 or 3 standards for different EGP's and idpr's with no architecture. 4) Make a new architecture which allows "Megadomains with ouija board glue". There is no consensus on a meta-routing architecture, and in it's absence the IESG felt handicapped in guiding the work of routing protocol development. In the absence of any guiding principles, the IESG felt that IDPR should get all the implementation and operational experience possible and welcomes all measure to make this happen.