Re: RE: AD request / L2 Triggers Chapter Statement

James Kempf writes:
> RFC 2460 has an explicit requirement on L2 for IPv6 that it support path
> MTU discovery

Uh ... no.  Path MTU discovery is an L3 issue; it's performed using
ICMP messages, and really has nothing to do with the L2.  There's no
such thing as "Path MTU Discovery on Ethernet," for instance.  The
only requirement in this area is that every link that supports IPv6
must have an MTU of at least 1280 octets.  Note that this is a static
requirement: IPv6 doesn't ask for any sort of "negotiation" with the
L2 in use.  Instead, the IPv6 documentation itself demands a minimum
MTU value that can be used.

Of course, a given implementation may have some any sort of elaborate
internal software capability negotiation mechanism desired by the
system architects.  That's of absolutely no consequence to either this
RFC or to the IETF in general.

> and that layer 2 either handle segmentation and reassembly
> itself or that this be done in the driver by a shim.

The only use of the word "segment" in that RFC refers to the Routing
Header option (section 4.4).  I assume that you're talking about IPv6
fragmentation and reassembly instead.  This happens to be another L3
issue -- it's dealt with using L3 headers, and involves replication of
L3 data.  It doesn't involve the L2 in any special way, other than to
transmit the data.

Again, the L2 is agnostic with respect to this issue.

> The requirment is
> abstract, in that it does not specify how the requirement should be
> implemented for a particular layer 2..

Right.  Negotiation or signaling, if any is indeed required, is a
local implementation issue.  It's explicitly not documented *HOW* IPv6
goes about getting the sorts of links it needs because this
implementation detail necessarily *will* vary on each system.

> As another example, RFC 2464 provides explict details as to how IPv6 is
> transmitted over IEEE 802 type (Ethernet) layer 2 networks. It has
> traditionally been that case that such RFCs describe how to implement IP
> over a particular layer 2. These types of RFC are very specific to a
> particular layer 2.

Right.  That document describes exactly what IPv6 packets look like on
802 media.  It doesn't describe what the internal interfaces necessary
to do that might look like.  You can implement RFC 2464 using STREAMS,
function calls, system calls, or just about anything you care to.

> Both of these are standards track RFCs.

Correct, and rightfully so.  The triggers document, however, is quite
different.

> I would be interested to hear from you what specific characteristics of
> the proposal for a layer 2 triggers specficiation you find to be any
> different from the existing cases.

draft-corson-triggered-00.txt says:

   The exact composition of an L2 trigger is also not specified here.
   An L2 trigger MUST contain the MAC address of the adjacent neighbor
   interface.

The problems are:

	- this does nothing at all to fix the problem on 802-like
          bridged media, which is clearly where the hardest problem
          exists.

	- this does not add any new mechanisms that were missing in
          any existing L2 protocols.  The ones that were broken remain
          so, and the ones that were already fixed remain so.

	- for the media where the problem is already fixed (point-to-
          point links, and other media that give positive disconnect
          indication), the problem is *already* fixed for that medium;
          it's merely an implementation issue.

In other words, other than describing some sort of abstract and purely
internal internal software interface issue, I don't see that this
draft fixes anything that needs to be fixed.

If someone wants to have a motherhood-and-apple-pie draft that (in
effect) says, "it'd be really nice to give L2 indication of link
up/down to IP, if you can manage it," then I guess I understand the
draft in that light, but I don't see any significant value in doing
that.

In general, I don't think that the IETF is really the best vehicle for
setting internal software design guidelines.  There are other groups
that typically do such things (e.g., X/Open), and I don't see how the
IETF can or should properly address such a broad (and irrelevant for
interoperability) issue.

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