Minutes interim-1991-iesg-06 1991-09-12 16:00
minutes-interim-1991-iesg-06-199109121600-00

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
<draft-ietf-iplpdn-ipoverframerelay-03>
- Inverse ARP <draft-ietf-iplpdn-inarp-02>
- IGP Applicability Statement <draft-iesg-commonigp-00.txt>

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.