Re: A few comments on LINK version 11

Hi, Joe, and thanks for a quick response.

Comments/responses inline...

Spencer

--- Joe Touch <[email protected]> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/