The Minutes below should be considered a Rough Draft - 4/01/92 Megan

CURRENT_MEETING_REPORT_


Reported by Gary Malkin

RIP-V2 Working Group Minutes

Status Update



Chairperson		Gary Scott Malkin / gmalkin@ftp.com

Mailing List		ietf-rip(-request)@ftp.com

Date of Last meeting	San Diego IETF / March 18, 1992

Date of next meeting	Boston IETF / July 1992

Progress		Settled on final packet format and new field
			definitions.  Determined that no backwards
			compatibility issues exist.  Made first pass
			at listing the objects needed in the MIB.

Milestones:
	Boston		Final review of RIP-II I-D and submission into
			the standards track.  First review of RIP-II MIB.

	Washington	Review of implementations.  Final review of MIB.

	TBD		Given successful implementation experience,
			advancement of RIP-II to Draft Standard.  Submission
			of MIB into the standards track.

	TBD		Final meeting to achieve closure on any pending
			issues.



Agenda

	o Review of Working Group charter

	o Review of newest draft document

	o Discussion of backwards compatibility issues

	o Discussion of security issues

	o What needs to go into the MIB


The charter was accepted unchanged.

There were two changes to the packet format do to some confusion about
the Routing Domain field.   The RD field, as defined, is a per packet,
user configurable parameter.  It has, therefore, been moved into the
Must Be Zero field in the RIP packet header.  The RD field which was in
the RIP entry has been renamed to the Route Tag.  It is used to indicate
that the route was learned from an external source.  The exact use of this
field is still under discussion; however, it has been determined that
the contents of the RT field must be preserved when that route is
propagated.

The subsumption of routes, made necessary by the addition of the subnet
masks is still under work.  The issues accompanying supernetting were
also discussed, but no final solutions were reached.  We did determine
that there should be no user controls for this, since this could lead
to black holes if routers were dis-similarly configured.  It was decided
that supernetting could not be used in the presence of RIP-I routers.

It should be explicitly mentioned that next hop is an advisory value.
Next hop may also only be used for the directly connected network
over which it was received.

It was decided that addressless links would not be considered.

We will need a new route type for MIB-II.

It should be mentioned, if RFC 1058 does not, that split horizon
does not apply to routes learned via routing protocols other than RIP.