Re: RE: AD request / L2 Triggers Chapter Statement

> From: Lloyd Wood <[email protected]>

> ...
> Exactly. having e.g. a daemon conclude that or ifconfig mark the
> interface as down from secondary evidence is not the same as having
> the L2 driver learn about from hardware and do the same thing
> reliably, but the former is more common in endhosts than the latter.

That you trimmed these words of my strikes me as an quoting out of
context of what I said:

] I've forgotten more than just the details, but I think I remember
] writing BSD-style FDDI drivers that downed the interface on bad
] situations such as stuck-BEACONing. 

If I recall correctly, that had nothing to do with daemons, because you
deal with FDDI problems such stuck-BEACONing in the driver and don't
have any daemons for help (or at least that was the case in my code).


> (Boot up a redhat-using laptop sans network connection and wait 90
> seconds for it realise that there isn't going to be any network
> traffic. In a sanely engineered world, not having anything plugged in
> to the ethernet port should be the instant dead giveaway.)

90 seconds is far longer than necessary, particularly when you are
talking about booting up instead of a disconnection of a working link.
I'm sorry RedHat is so slow, but since the overall topic is about L2s
that were present but break instead of L2s that never existed, since
I wasn't talking about Linux, and since the common BSD `routed` does
not run on Linux (for lack of 4.4BSD-Lite "routing sockets"), I don't
see its relevance.

On the other hand even 90 seconds is faster you can reasonably hope
to do anything with an existing TCP/IP connection no matter how many
L2 triggers you have, because no L2 trigger on your laptop is going
affect the far end of a TCP connection.

I think you are continuing to make much the same error of circular
reasoning as the people who argue that TCP must be thrown out, because
mobile wireless modems or G3 phones are completely different than
anything that has come before.  You are assuming it is impossible for
a L2 driver to do as I said and diddle the IFF_RUNNING or IFF_ON bits
in order to reach your conclusion, just as they assume that TCP never
before ran over modems slower than 9600 bit/sec with large error rates
or long drop-outs (e.g. the effects of "call waiting" or needing to
hang-up and redial).


Vernon Schryver    [email protected]

_______________________________________________
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/