Re: What's the good word?

Fred Baker <fbaker@acc.com> Fri, 15 May 1992 01:43 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04606; 14 May 92 21:43 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17791; 14 May 92 21:49 EDT
Received: from harvard.harvard.edu by NRI.Reston.VA.US id aa17780; 14 May 92 21:49 EDT
Received: by harvard.harvard.edu (5.54/a0.25) (for IETF-archive@nri.reston.va.us) id AA16006; Thu, 14 May 92 21:47:52 EDT
Received: by Xylogics.COM (4.12/4.7_jlv1/7/90) id AA07840; Thu, 14 May 92 21:47:38 edt
Received: from saffron.acc.com (2040c081) by Xylogics.COM (4.12/4.7_jlv1/7/90) id AA06200; Thu, 14 May 92 21:47:35 edt
Received: by saffron.acc.com (4.1/SMI-4.1) id AA13461; Thu, 14 May 92 18:45:21 PDT
Date: Thu, 14 May 92 18:45:21 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9205150145.AA13461@saffron.acc.com>
To: anil@levers.enet.dec.com
Subject: Re: What's the good word?
Cc: ietf-rip@acc.com

Anil:
>>     1) The description of the "Routing Domain" and "Subnet Mask" sections
>>        are rather sketchy.  A clearer explanation of "RIP clouds" (and
>>        why they are needed), "subsumption", etc would be very helpful.

I agree that the Routing Domain is a bit of a black box.

The subnet mask is an IP facility that aggregates IP addresses into
blocks.  This is fundamental to IP Routing.  You might take a gander at
RFC 950.

Route subsumption is also rather basic to IP routing.  The whole idea
is to reduce the amount of information systems that have no "need to
know" have to deal with.  For example, if I would select the same next
hop to get to subnets A.B.C.0 and A.B.D.0, and D = C + 1, then maybe I
only need to advertise a route to A.B.C.0 with a single bit wider
subnet mask.  This is called route subsumption.

specific example:

If I know that:
	191.154.88.0, subnet mask 255.255.255.0, next hop is 191.154.3.8
	191.154.89.0, subnet mask 255.255.255.0, next hop is 191.154.3.8

Then I only need to advertise:
	191.154.88.0, subnet mask 255.255.254.0, next hop is me
					    ^

>> 
>>     2) The "Multicasting" section doesn't explain why IGMP (IP multicast)
>>        is a requirement.  This question, which was brought up on the
>>        list a couple of weeks back, drew some responses on
>>        why IP rather than hardware multicast is needed which left
>>        me somewhat confused.

>>        One school of thought held that since RIP packets are exchanged
>>        at the IP level, hardware addresses should not be mentioned.
>>        This (in my opinion) doesn't seem to be a sufficient reason to
>>        require yet another protocol - you want to make it easy for
>>        RIP-1 to be upgraded.  Another view said that it helped in ignoring
>>        certain messages, but it seems to me that there are other fields
>>        that can be used in the new format to achieve this, if it is
>>        indeed a requirement..

I don't know of anyone that is proposing that RIP-II rely on IGMP.
What IS required is that a packet be able to to be multicasted by a
RIP-II system and ONLY heard by other RIP-II systems, much as in an
Ethernet Multicast.  However, the attribute is required on more than
Ethernet - it is required on 802.5, for which *IP* has a functional
address, but IP client protocols do not, point to point links, and
other environments.

OSPF does the same thing.  OSPF hellos are not propogated across the
WAN, they only go to the immediate neighbors of an OSPF router.
However, those neighbors are functionally identified as "OSPF Routers"
and "OSPF Designated Routers" by the choice of destination IP address -
either 224.0.0.5 or 224.0.0.6 respectively.

On Ethernet and FDDI, RFC-1112 defines a MAC multicast address derived
from the IP Multicast address.  It's not a matter of "the MAC address
need not be specified", but "specifying the IP address and the media
type unambiguously specifies the MAC address."

Fred