Hi, Joe, and thanks for a quick response.
Comments/responses inline...
Spencer
--- Joe Touch <touch@ISI.EDU> wrote:
> Spencer Dawkins wrote:
>
> Hi, Spencer (et al.),
>
> These are useful comments, but in the interest of
> moving forward on this
> version, continued wordsmithing is less useful than
> catching typos and
> complete errors at this point.
>
> It would be useful if you could identify which of
> these issues you feel
> are show-stoppers at this point.
Actually, it's been a long time since I thought LINK
had show-stoppers. I think I'm wordsmithing for
publication.
>
> --
>
> With regard to bcast/discovery, these issues have
> been addressed before;
> no version of text will be 100% clear to any set of
> readers. (detailed
> reply below)
I believe you.
>
> With regard to references, IMO, URLs are
> inappropriate for RFCs unless
> there are no alternate sources, and only for
> non-normative (to give
> credit, NOT for 'additional info'). This is because,
> as you point out,
> most of the URLs have moved already. Google/etc will
> suffice, and we
> shouldn't waste space or energy on such empemeral
> data.
This works for me...
>
> Joe
>
> ...
> > 5 Broadcasting and Discovery
> >
> > Subnetworks fall into two categories:
> > point-to-point and shared. A
> > point-to-point subnet has exactly two endpoint
> > components (hosts or
> > routers); a shared link has more than two,
> using
> > either an inherent
> > broadcast media (e.g., Ethernet, radio) or on a
> > switching layer
> > hidden from the network layer (switched
> Ethernet,
> > Myrinet [MYR],
> > ATM). Switched subnetworks handle broadcast by
> > copying broadcast
> >
> > Could this sentence say "by forwarding broadcast
> > packets on all other
> > interfaces to ensure..."?
>
> The current text implies "send TO each destination";
> sending ON each
> interface makes implications about the technology
> which don't apply to
> some multistage switched nets.
Point taken (thanks!). I was mostly asking to replace
"copying" with "forwarding".
>
> > packets to ensure each end system receives a
> copy
> > of each packet.
> >
> > Could we insert "Centralized databases also insert
> new
> > failure points and
> > scaling hot-spots into the network." before the
> last
> > sentence in the
> > following paragraph?
>
> Sure. But it's somewhat obvious (i.e., do we really
> need to say WHY
> centralization is bad?).
On this point, and a couple of others in my previous
comments - the intended audience for LINK is
subnetwork designers who don't have a lot of
experience with TCP/IP (beyond surfing the net over
lunch), so I'd like to call attention to scalability
more explicitly in this document than would be
appropriate for most I-Ds. For almost any other I-D, I
would agree with your response here.
>
> > The lack of broadcast can impede the
> performance of
> > these protocols,
> > or render them inoperable (e.g. DHCP). ARP-like
> > link address lookup
> > can be provided by a centralized database, but
> at
> > the expense of
> > potentially higher response latency and the
> need
> > for nodes to have
> > explicit knowledge of the ARP server address.
> > Shared links should
> > support native, link-layer subnet broadcast.
> >
> > 6 Multicasting
> >
> > Receivers also need to be designed to accept
> > packets addressed to
> > some number of multicast addresses in addition
> to
> > the unicast packets
> > specifically addressed to them. How many
> multicast
> > addresses need to
> > be supported by a host depends on the
> requirements
> > of the associated
> > host; at least several dozen will meet most
> current
> > needs.
> >
> > The last phrase doesn't parse well for me. Is it
> > saying "few hosts
> > must accept multicast packets from more than a few
> > dozen multicast
> > addresses"?
>
> Yes. Since it appears to have worked, perhaps it's
> sufficient. :-)
OK, but while I may not be the brightest candle in the
candleabra, some readers of this document may have
more trouble figuring it out than I did, especially
given the target audience.
But my comment ALSO didn't do what I was trying to do
- come up with a nearest-multiple-of-ten number, to
say "few hosts must accept multicast packets from more
than ___ hosts". "Few dozen" and "several dozen"
probably do have the same number of significant
digits!
Any ideas (from anyone) on what a reasonable "minimum
maximum" number would be for this sentence?
>
> > On low-speed networks the multicast address
> > recognition function may
> > be readily implemented in host software, but on
> > high speed networks
> > it should be implemented in subnetwork
> hardware.
> > This hardware need
> > not be complete; for example, many Ethernet
> > interfaces implement a
> > "hashing" function that passes all of the
> multicast
> > (and unicast)
> > traffic to which the associated host
> subscribes,
> > plus some small
> > fraction of multicast traffic to which the host
> > does not subscribe.
> > Host/router software then has to discard the
> > unwanted packets that
> > pass the hardware filter.
> >
> > There does not need to be a one-to-one mapping
> > between subnetwork
> > multicast address and IP multicast address. An
> > address overlap may
> > significantly degrade the filtering capability
> of a
> > receiver's
> > hardware multicast address filter. A subnetwork
> > supporting only
> >
> > Is this sentence saying "If more than one IP
> multicast
> > address makes into
> > a subnetwork multicast address, this many-to-one
> > mapping may significantly
> > degrade the filtering capacity of a receiver's
> > hardware multicast address
> > filter", or something else? "Address overlap" is
> too
> > ambiguous for me...
> >
> > broadcast should use this service for multicast
> and
> > must rely on
> > software filtering.
> >
>
> The rest of the sentence explains it - hardware
> stops being useful and
> thus requires software.
This probably was clear enough in version 11. I agree
with your response.
Again, thanks for all your help with this document!
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Tue Jun 11 2002 - 16:31:37 EDT