Re: RE: AD request / L2 Triggers Chapter Statement

Lloyd Wood writes:
> 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.

Agreed.  For what it's worth, I work for an endhost vendor that does
indeed have the latter on some interfaces.  It's certainly not as
common a feature as one might like, but it's not wholly unknown.

In any event, this isn't something the IETF can fix.  The IETF writes
documents that describe protocols.  It really isn't in a position to
force vendors to write any particular code -- including code that
works the way some particular users would like to see it work -- and
writing documents doesn't solve the problem that vendors don't always
implement features that users want.

Yes, when possible and practical, L2 interfaces ought to tear
themselves down when they become unusable so that they don't represent
black holes to the rest of the IP system.  L2 interfaces ought to
interface with management software such that alarms get delivered in a
reasonable manner and diagnostics can be run to pinpoint problems.
This is all part of the existing body of common networking design
knowledge.  The fact that these things often aren't the case, even
when the solutions are well known and the L2 mechanisms are part of
the existing (mostly non-IETF) standards, points to holes in the
implemented feature sets (and original requirements), not necessarily
a lack of new protocols.

In other words, if the vendors aren't implementing the existing things
that are already known, why would adding a *new* thing to the long
list of standards make the situation any better?  I think we need to
fail collectively after having *tried* the solutions we already know
about before we set off to create new solutions, and I don't see that
this is the situation.

> (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.)

That's an even easier fix.  You have the source.  Nuke the IFF_RUNNING
bit on carrier loss.

Be prepared to be incompatible with a wide array of equipment after
you've done that, including (probably) switches with long spanning
tree timeouts.

(And note also that the POSIX standards require you to fail a
connect() call immediately when the requested destination isn't in the
local forwarding table.  Thus, ripping up the IP interface on failure
is enough by way of notification to new connection attempts.  Of
course, if that interface is broken, you have other problems.)

-- 
James Carlson, Solaris Networking         <[email protected]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

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