Re: RE: AD request / L2 Triggers Chapter Statement

Lloyd Wood writes:
> On Fri, 5 Jul 2002, Joe Touch wrote:
> 
> > Phil Neumiller wrote:
> > > I am sorry about that "sand" comment.  It seems the arguments
> > > quickly get circuitous.  What we are suggesting is something
> > > really subtle.
> > >
> > > A).  IP needs to create a standard interface method on its
> > > unspecified bottom half. B).  It already has one on the top,
> > > namely sockets.
> 
> sockets isnt' a standard.
> streams isn't a standard.

That's not quite the case.  Both are standardized in the SUSv2.
Sockets is in the XNS:

http://www.opengroup.org/pubs/catalog/c808.htm

and the STREAMS user-level interface is in XSH and XBD, which are also
IEEE Std 1003.1-2001 (POSIX).

The kernel bits are also standardized.  DLPIv2 is C811:

http://www.opengroup.org/pubs/catalog/c811.htm

TPI is C810:

http://www.opengroup.org/pubs/catalog/c810.htm

and, of course, the SVID.

Just because something isn't part of the IETF doesn't make it
"non-standard."  Just because something *might* need to be
standardized does *not* mean that it needs to be done within the IETF.

There are many groups that are equipped to deal with standardizing
software interfaces for various platforms.  If you're interested in
contributing to that work, then I do recommend that you join such a
group.  The IETF isn't the 'droid you're looking for.

> > > This is quite different than saying, all L2s must do this or that.
> > > What we want is a mechanism to pass L2 information in a standard
> > > way up to and through the IP stack.
> >
> > Given that IP is stateless and connectionless,
> 
> As if.
> 
> A link interface is allocated an IP address and mask. That's state.
> The link interface is either up or down. That's your immediate
> connection to the subnet.

Agreed.  However, the state essentially disappears above IP.  A
properly implemented TCP neither knows nor cares about the state of
interfaces.  All it cares about is sending and receiving segments.
These somehow either make their way to a remote destination or are
lost.

In particular, if you rip up TCP connections merely because an IP
interface goes down, then that's a rather horrific bug.  TCP is
*supposed* to survive re-routes, whether in the local system or in an
intermediate router.

> > what would IP do with any particular information it gets?
> 
> Pass it on.

To whom?  Such changes affect the IP forwarding ("routing") table in
most cases, and need to be communicated to routing protocols.  If you
do QoS, then changes might affect any int-serv reservations you have,
but that's really just a special case of a routing protocol.

Such a change should *not* touch any transports or applications,
however.

> > There is no way to push information through a stateless system into a
> > stateful one (e.g., TCP, or to application layers, e.g., routing
> > protocols or user applications that are carried as data inside transport
> > protocols).
> 
> You're saying that if a link goes down there's no way to tell routing
> about it, because IP gets in the way and routing is above IP?
> (Fortunately, routers that know about links and know about routing
> tables can use the information regardless if it's useful.)

Agreed.  Only routing can care.

> When the link on a host goes down, will the TCP stack continue to
> accept data from the application even though it can't be sent? (Phil's
> kick-TCP-when-the-link-comes-up also springs to mind.)

In short: *YES!*

There are many reasons this is true.  The link it was once using might
not be the only way to get to the desired destination.  Even if it's
the only way to get there, the link may still come back soon enough to
recover.

If this weren't the case, then wouldn't you also want to kill off TCP
sessions when you see a single ICMP Destination Unreachable?  What's
the difference between a link that flaps on an intermediate bottleneck
router versus one that flaps on the local host?

If you are stuck using a stack that does otherwise, then that stack is
just plain broken.  You probably should upgrade to one that works
right.

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