Re: RE: AD request / L2 Triggers Chapter Statement

> From: Lloyd Wood <[email protected]>

> > Again, why can't the host's applications that care open a routing
> > socket and to hear all about interfaces coming and going?
> >
> > Or is all the world a Solaris box?
>
> interfaces going up/down is not the same as interfaces coming or
> going.

What's the substantive difference?  
Shouldn't a good L2 driver twiddle an IFF_ON or IFF_RUNNING bit when
bad things happen, and so signal routing socket listeners?
I think reasonable `routed` implementations notice when an Ethernet
cable is disconnencted.  What's the difference between that case
and a datagram application on a mobile phone suffering some sort of 
fading or dropped handoff?

Granted, I'm playing a little loose with the details.  In the common
BSD `routed` code, the daemon notices the error counts that result
from a disconnected Ethernet cable or a kaput FDDI ring and marks the
interface down.  UDP applications then start getting errnos equivalent
to ICMP Unreachables.  TCP applications start their normal 90 to 300
second timeouts, if they send any traffic.  I don't know about telephony
appliations, but UDP conferencing applications tend to have enough
regular traffic to notice a dead link.  However, from what I've seen,
they tend follow the primary rule of programming and ignore errors
they can't handle.


> > > ...
> > > A simple function call to find out would suffice. No MIB. Minimal
> > > running code. But routers are integrated beasts, while typical
> > > endhosts aren't.
> >
> > What are the decades old getifaddrs() and the merely decade old
> > routing sockets, chopped liver?
>
> And what gets to mark the interface as up or down?

Why not the L2 driver?

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.

I fear this discussion has again wandered into the weeds of hypothenticals
far from practice.  The separateness of IP from L2 is more evident in
cloud diagrams than in code.  For that matter, the distance between
TCP and L2 is larger in theory than in practice, at least if you've
ever made a system page flip or use hardare for the TCP and UDP
checksums.  For example how does TCP know whether compute checksums
when some of the L2 interfaces on a system has checksum hardware and
some doesn't?  Teaching a system to page flip tends to make the L2 driver
want to know about stuff in the application stratosphere above TCP or UDP.


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/