Re: RE: AD request / L2 Triggers Chapter Statement

James,

RFC 2460 has an explicit requirement on L2 for IPv6 that it support path
MTU discovery and that layer 2 either handle segmentation and reassembly
itself or that this be done in the driver by a shim. The requirment is
abstract, in that it does not specify how the requirement should be
implemented for a particular layer 2..

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.

Both of these are standards track RFCs.

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.

                jak

----- Original Message -----
From: "James Carlson" <[email protected]>
To: "Phil Neumiller" <[email protected]>; "Lloyd Wood"
<[email protected]>; "JinHyeock Choi" <[email protected]>;
"ÀÌÁöÈÆ" <[email protected]>; "Alper E. YEGIN"
<[email protected]>; "Mc.Ky" <[email protected]>; "Behcet
Sarikaya" <[email protected]>; "James Kempf"
<[email protected]>
Cc: "Einar Vollset" <[email protected]>;
<[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; "Vernon Schryver" <[email protected]>;
"Kamesh Medepalli" <[email protected]>
Sent: Monday, June 17, 2002 12:21 PM
Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement


> Phil Neumiller writes:
> > > In contrast, the "triggers" proposal changes *nothing* about the
bits
> > > on the wire.  The bits remain the same; only the internal design
> > > (perhaps) changes.
> >
> > Yes, this is the whole point.  To this day, IP as defined by the
IETF has
> > NEVER described how an L2 itself might interface to IP.
>
> Right.  Nor has the IETF described how IP interfaces with buffer
> and/or memory management.  Nor how it interfaces with event logging.
> Nor what sorts of debug facilities are needed.  These are all
> considered to be implementation details that are outside of the domain
> of IETF standards.
>
> >  That is indeed
> > what we are struggling with.  I realize its a new concept.  Its the
wire(s)
> > between the link layer and the internet layer that needs
specification.
>
> What wire?
>
> > Why *this* was never done escapes me.  The IETF is more than happy
to
> > say here is a dumb L2 with a payload like this and here is how we
> > stuff IP bits into it.  The IETF heretofore has NEVER been
interested in
> > how an L2 may interpret the TOS field or TTL for instance across an
> > L2 tunnel.
>
> Now wait just a minute -- that's a very different thing.  Interpreting
> the bits inside the TOS [DSCP] field and changing the per-hop behavior
> based on them is indeed an externally observable behavior.  Where
> *possible*, I think the L2-specific documents that talk about how to
> carry IP over a given L2 should deal with these issues.
>
> I never said differently.  Please don't put those words in my mouth.
>
> The QoS implementation case is utterly different from describing an
> "L2 triggers" standard.
>
> >  How can the IETF EVER hope to build QoS if it continues
> > to limit itself to this limited method of specification?
>
> Just how did we wander off-topic into QoS?
>
> In any event, the problem isn't (and never has been) in the
> comparatively simple problem of querying interface capabilities and
> dealing with different feature sets.  Folks who build real IP
> implementations have dealt with that issue for decades.  The really
> hard problem is in what one *does* with any of those features, and
> this proposal doesn't make that hard problem any easier.  That hard
> problem accounts for much of the lack of deployment.
>
> >   Perhaps best
> > effort is the end-all???   Maybe we don't really need to charge for
> > mobility, QoS, and security?   This is precisely where IP needs to
> > mature.  The bits on the wire may very well be affected (in the
> > time or frequency domain) if IP+xport had a mechanism to allow it.
>
> Certainly.  All the upper-level things are in the domain of the
> diff-serv working group to define, and the lower-level bits belong to
> the (mostly non-IETF) L2 designers.
>
> > Most wireless interfaces have a variety of speed settings.
Generally the
> > longer the distance the slower the speed.  When you add mobility and
> > QoS to this mixture it gets real ugly real fast UNLESS IP matures.
>
> I don't see how that's a protocol issue.  It's a design issue.  The
> two are quite different.
>
> > My claim, is that IP IS NOT DONE FOR WIRELESS.  Its only
> > just begun.  If you shoot me down here in this BOF, other more
powerful
> > wireless Jedi will follow me!!! :-)
>
> Hey, knock yourself out.  You don't have to shoot me down to proceed.
> If you think it's useful, stop listening and just drive on.  However,
> upper case letters to the contrary, I still remain to be convinced
> that this helps in any measurable way.
>
> Lloyd Wood writes:
> > On Mon, 10 Jun 2002, James Carlson wrote:
> > > Given that the changes make no observable difference, how does it
> > > matter?
> >
> > A similar argument can be made for TCP congestion control
algorithms,
>
> Actually, no, it can't.  With TCP congestion control, the differences
> can be observed on the wire -- the timewise behavior changes.  What
> the congestion control algorithms *don't* specify is how you *must*
> implement it.  All they specify is the behavior, in graphic detail.
>
> In the case of these L2 triggers, however, there's simply no
> difference on the wire at all.  A box that implements this feature by
> proprietary means will be *indistinguishable* from one that implements
> it using the new protocol.  There's nothing to observe, because the
> feature is purely an internal interface, not an actual protocol.
>
> Phil Neumiller writes:
> > > A similar argument can be made for TCP congestion control
algorithms,
> > > which are merely implementation features that are internal to the
box,
> > > and do not specify protocol bits on the wire. TCP congestion
control
> > > is a host implementation feature, and shouldn't be standardised!
> >
> > I was going to say the same thing about routing and QoS.  Routing
> > affects spacial aspects of the bits on the wire(s) but not the bits.
>
> This is incorrect for exactly the same reason.  Those behaviors are
> good examples of things that *are* visible outside of the box and that
> can be specified in terms of how the box itself behaves.
>
> Specifying that an L2 interface must send such-and-such signal into IP
> on some event is *not* observable outside of the box.
>
> JinHyeock Choi writes:
> > Few will doubt that it is useful for the link layer to be able to
send event notifications up to IP
> > layer,
>
> Right; no disagreement there.
>
> > especially for fast handover in wireless environment. And if the
link layer and the IP layer
> > reside in one system, we can implement the system to send suitable
information upward.
>
> Sure.
>
> > But what if the link layer and the IP layer are in separate systems?
>
> Huh?
>
> If the link layer is on a separate system, then some sort of
> networking protocol connects that separate system with the one that
> does IP.  That protocol essentially defines a tunnel.
>
> Tunneling protocols already have their *own* signaling for exactly
> this reason, and the local endpoint behaves as the L2 layer and
> signals (as L2s have *always* done) in a manner appropriate for the
> local system.  There's no reason that anything new is needed here.
>
> > What if the link layer in one
> > system wants to send notifications to the IP layer in another
system? For example, is it possible
> > for an AP to send a notification to a mobile node or an access
router? I think this kind of ability
> > is useful. We found some technical problem can be solved more easily
with L2 and L3
> > cooperation.
>
> That sounds like a different case than the one described above.
> You're basically describing integrating L2 reachability information
> into L3 -- so that (say) a failure of a bridge or switch port notifies
> other hosts on the network so that they can (for example) rip up
> ARP/ND entries and reroute traffic.
>
> That sounds like a great idea, but it's not IP, and not part of the
> IETF.  I would suggest bringing such a thing up with IEEE or doing it
> as a special proprietary hack.
>
> > access router as soon as possible. But there are some problem under
current neighbor
> > discovery protocol. For more detail, confer 'Mobility Support in
IPv6 (draft-ietf-mobileip-ipv6-
> > 17.txt)' 7.5 and 'IPv6 Fast Router Advertisement
(draft-mkhalil-ipv6-fastra-00.txt)'. Because
> > of these, the standard (RFC 2461) change is suggested. But we can
solve these problems more
> > easily if an AP caches suitable Router Advertisement message and
sends it to an arriving mobile
> > node. For more detail, confer 'Fast Router Discovery with AP
Notification (draft-jinchoi-
> > l2trigger-fastrd-00.txt)'.
>
> Yes, these are more examples of things that I don't see a need to
> standardize.  Everyone who implements this stuff knows that it's a
> good thing to send advertisements as soon as L2 goes up.  Is that
> something that actually needs to be "standardized?"  Why?
>
> > We believe that the above is not sole example. Moreover it will be
nice for other standard body
> > (IEEE 802.11) to nofify them what kinds of triggers are needed to
optimize IP
> > performance. Did IETF provide input for 3GPP?
>
> You're talking about two things, I think.  802.11 emulates an
> Ethernet, and 3GPP is using PPP.
>
> > I guess the following questions are to be considered.
> > 1) Is L2 trigger useful for Internet?
> > 2) Can we improve the current work on L2 trigger?
> > 3) Is it appropriate to work on L2 trigger in IETF WG?
> >
> > IMHO, the answers to all are positive as I wrote above.
>
> In my opinion, all of those are negative.
>
> Phil Neumiller writes:
> > > And this has significantly influenced the design
> > > of the IP and TCP protocols when the Old Arpanet NCP had to be
redesigned
> > > for a more heterogeneous and wireless environment!
> >
> > Yes, and it worked fine for non-realtime, non-commercial, best
effort traffic on
> > a relatively lightly loaded and a much smaller global Internet.  The
bu$iness world
> > wants more.  MUCH more.  Mobility is a "chargeable" service.  Why
aren't
> > mobile Internet service providers popping up?  Because its hard too
> > do.
>
> Or because it's just plain unnecessary.  I can use any of IPsec,
> Mobile IP, ssh, Kerberos, and L2TP with my mobile connection.  I can
> use them all *today* without bothering to pay my ISP extra.
>
> Why would I want to pay extra for something I can already do?
>
> > Why is
> > it hard to do?  Because the IETF has become pompous and monolithic
and
> > slow to change.
>
> Bah!  I'm going to try to pretend that you're somehow not calling *me*
> pompous, but I don't think it's going to work.
>
> >  IP IS NOT PERFECT!  IP over everthing inspired a huge
> > growth spurt along with the WWW.  Instead of standing around in awe
at the
> > marvelous Internet, can we get on with improving it finally????
>
> I've yet to see a proposal that helps.
>
> > > Maybe instead of relying on a connection-oriented subnetwork and
dealing
> > > with "handover" problems it might be better tu use a basic
datagram
> > > subnetwork (remember - IP does not necessarily require a "link"
layer but
> > > assumes what used to be called a "local network") and put the
complexity of
> > > signaling and end-to-end aspects on a higher layer.
> >
> > Jeesh, how can a high layer work blindly!  You are making my point
for me!
>
> Blindly?  What is ECN?  What is diff-serve?  How much work has already
> been put into this and what does this proposal actually contribute?
>
> I'm really failing to see how this minor local interface hack -- which
> already exists, albeit in proprietary forms, in all of the systems
> I've ever used -- actually helps extract the fine *path-related*
> information that's required.  All the world isn't in that last hop.
>
> > > implement artefacts such as slow start and a separate congestion
window in
> > > order to do a good job. In my opinion this is the real problem we
are facing
> > > and the question remaisn whether this is a "protocol" issue or an
OS issue;
> > > in this respect I like the ISDN Refernce model which has separate
"planes"
> > > for these aspects.
> >
> > ...and these issues with TCP are complained about bitterly in the
various
> > transport WGs.  Isn't the solution becoming obvious???
>
> Yes and no.  One thing that's obvious is that getting L2 information
> about the very last hop tells you precisely *nothing* about the state
> of the network on the N-2 other hops between the communicating peers.
>
> > > TCP has never been designed as a real-time end-end protocol; maybe
the
> > > wireless people ought to define such a beast on top of IP and use
the packet
> > > radio techniques for the wireless network instead.
> >
> > We are in the process, but we keep running into people that want to
impede
> > our progress!! :-)  The first step in building a closed loop control
system for
> > handover, mobility, routing, and QoS is the feedback loop, i.e. L2
TRIGGERS!!!
>
> L2 triggers so far just talk about link up/down.  Where, exactly, is
> this feedback loop?
>
> Phil Neumiller writes:
> > A more systemic question might be is IP mobility important to the
Internet
> > community?  Let's face it, mobile IP has seen scant deployment in
its
> > years of existence.
>
> True.
>
> >  Why?
>
> In part because there are solutions that work just fine and are
> nowhere near as complex.  It's a classic optimization problem: Mobile
> IP attempts to address *all* of the problems, and solutions that
> address just some of the interesting problems turn out to be easier to
> deploy and use.
>
> >  Obviously its missing thing that would make it
> > commercially viable.  The 3G guys worked hard to add some of these,
> > but 3G is not necessarily moving that fast.  The hot spot, WLAN,
WPAN,
> > ad hoc, mesh community is moving much faster.  There are many cheap
> > radios available here and much more can be done with them quickly.
> > L2 triggers are a win-win since they benefit 3G, 4G, WLAN, WPAN,
> > mobileip, and MANETs.
>
> I agree that L2 involvement is necessary to make IP interfaces work
> nicely.  But how does that involve a new specification of any sort?
> It's already the case that link up/down notification is a standard
> part of every decent IP implementation.  Are we saying that by writing
> a new document, we're going to somehow make the crummy implementations
> good?  That just doesn't seem likely to me.
>
> Alper E. YEGIN writes:
> > Precisely. 802.11 is an example where wireless L2 (access point)
does not
> > have to
> > reside on the access router. Therefore, wireless L2 might be aware
of
> > certain
> > events (link up, link down) per client, but communicating this to
the
> > interested
> > party (i.e., access router) requires a protocol between two.
>
> Yes.  This is really an 802 problem, and it should be addressed there.
>
> Mc.Ky writes:
> > > ...and these issues with TCP are complained about bitterly in the
various
> > > transport WGs.  Isn't the solution becoming obvious???
> > >
> > For very good reason the ISDN people have come up with a
3-dimensional
> > Reference Model where certain aspects of signalling, resource
management and
> > inter-layer coordination are delegated to separate planes in "the
third
> > dimension".
>
> Right.  It's exactly this that I'm hoping we can avoid.
>
> > TCP has attempted to resove some of these problems and it seems to
me that
> > we are now attempting to look for simioar kludges for IP - instead
of
> > accepting
> > the fact that we need a "control" plane with its own protocols for
> > inter-layer
> > coordination and singaling.
>
> That is, as I've said many times before, a local design problem.  It
> has nothing to do with any of the things that the IETF cares about.
> It doesn't affect the bits on the wire.  It has no effect at all on
> interoperability.  If folks want to standardize design issues, that's
> great, and there are many standards bodies that are willing to do it,
> but the IETF isn't the right one (or even a good one) for the job.
>
> > The question is: should the IETF get into this field or not? IMHO -
if I
> > look at
> > what is happening with MPLS we are already in there!
>
> Again, that's a different case.  MPLS and the associated signaling
> protocols *are* defined in terms of bits on the wire.
>
> You can implement MPLS any way you like *inside* your box.  You can
> pass messages.  You can make function calls.  You can even invoke O-O
> "methods."  Anything at all.  What matters in terms of the IETF is
> that the bits that come out are somehow conformant with expected
> behavior and interoperable with other implementations.
>
> L2 triggers affect neither behavior nor interoperability.  They're
> strictly internal.
>
> James Kempf writes:
> > I'd like to add slightly to Behcet's rsponse. As our work with
Motorola
> > and Behcet's work shows, it should be possible to utilize Layer 2
> > triggers with current 3G radio protocols, but not necessarily with
> > current 3G radio access networks. Reduction of handover latency
requires
> > modifying the connection-oriented model to reduce the amount of
state
> > involved in maintaining a connection with the mobile node.
>
> But do these L2 triggers appear outside of the box?
>
> The main issues I see addressed in this presentation appear to be:
>
> - lack of indication of remote port failure on an 802 bridge
>           (a well-known problem), and
>
> - an implementation that doesn't solicit for a new router
>           advertisement when the link status goes up again (apparently
>           an implementation flaw).
>
> While I agree that the former is a significant problem, I don't agree
> that it's something that ought to be addressed by way of the L2
> triggers draft, or even necessarily in the IETF.  Optimizing the
> important failure cases by providing some indication that reachability
> of a remote link has been lost in a bridged network is a significant
> issue for 802, and is one that needs to be addressed at the L2 level.
>
> As a counter-example, L2 layers that are defined differently (e.g.,
> PPP) do not suffer from this design flaw.
>
> --
> 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/