Subject: RE: [pilc] RE: AD request / L2 Triggers Chapter Statement

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Jun 2002 10:23:13 -0600 (MDT)

> From: Einar Vollset <[email-masked]>
> To: James Carlson <[email-masked]>,
>    Phil Neumiller <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, Vernon Schryver <[email-masked]>

> >> Yes, precisely WHY it needs to be STANDARDIZED!!! You are making
> >> my point for me.  Thanks!
> >
> >Sure, I can see why having interface standards would be nice, but
> >then, why the IETF at all?  Internal implementation details really
> >don't seem to me to be the domain of folks engineering protocols for
> >the Internet itself.
> >
> >This seems more appropriate for The Open Group or some other such OS
> >interfaces standardization body.
>
> I don't see how these triggers can be classified as internal implementation
> details.
> If these triggers are used in routing decisions, as they might be in
> mobile IP or MANET scenarions, then why should it be an OS standard?
> It makes sense to me that the there should be clear interfaces to 
> IP on "both sides" of the IP stack.
> Or am I missing something?

You're missing the nature of standards.  The IEEE does not standardize
nuts and bolts, and ANSI doesn't standarize CSMA/CD networks.  The IETF
standardizes some bits on wires, but not operating system interfaces.
POSIX is not about how many bits are in IP addresses and the IETF is not
about whether the operating system facilities that accept an incoming TCP
connection involve one, two, three, or four system calls.

Application and L2 code affecting routing decisions is decades old,
but still not a topic for the IETF.  As the author of the `routed`
daemon in a bunch of UNIX-like systems including NetBSD, FreeBSD, and
some major commercial UNIX systems, I agree that a standard for such
functions would be nice.  That there are at least four common but
incompatible UNIX ways for something like `routed` to tell the IP code
"add this route" is a royal pain, but it is a pain that has nothing
to do with the IETF.  As someone who has also written network hardware
drivers, I also agree it would be nice if there could be a standard
for how drivers talk to systems, but having dealt with standardized
messes like DLPI, prefer chaos.

To put the point in yet another, albeit offensive way, if you don't
see why the IETF has no business in the businesses oF The Open Group,
POSIX, and the other operating system API, ABI, and other **I groups,
then you probably don't know enough about the issues to be working on
the problem anywhere.  Whatever you come up with might work in a
particular mobile-phone platform, but it won't make the slightest
sense with STREAMS, DLPI, or even a real multi-processor (NUMA) sockets
system that is as BSD-compatible as possible for such a thing, because
you've probably never encountered those issues.

A standards committee is not the right venue for on the job training
about the subject being standardized.

Vernon Schryver    [email-masked]

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: James Carlson <[email-masked]>
Date: Mon, 10 Jun 2002 12:27:41 -0400

> I don't see how these triggers can be classified as internal implementation

On which network interface do these bits appear?  As best I can tell,
they don't.  They go from a network driver up to a network layer (or
perhaps higher).  They don't appear on any external wire.  They are
thus internal.

That argues that these *are* implementation details.  They're subject
to all the usual implementation detail problems: are these messages,
function calls, special dblk types, method invocations, or something
else?  What are the MT issues involved?  How do I send them over
DLPIv2?

Note that if there are multiple different ways to send these things,
depending on implementation particulars (and the charter draft hints
at this by mentioning C and Java bindings, among other things), then
there's much less hope of any sort of interoperability.  All that's
being defined is a "framework" or perhaps a list of requirements, and
not a protocol.  The IETF standardizes protocols.

> mobile IP or MANET scenarions, then why should it be an OS standard?

There are lots of things that are used in routing decisions that are
not part of any possible IETF standard.  For instance, the actual
design of an IP forwarding table is an implementation detail.  It's
not defined by an RFC.  That these things might be used in some direct
or indirect way by forwarding or routing is not an argument to do this
in the IETF.

> Or am I missing something?

I have no substantial disagreement there.  I just don't see how it's
an IETF issue at all.

Should there be variations of this standard for different system
architectures?  That, I think, is the key question.  If you're setting
up something that defines some sort of application interface, *and*
that interface cannot somehow be the same on all systems, then I
really question the value of doing that, at least within the IETF.
Part of the goodness of existing IETF standards is that they're
agnostic with respect to operating system architecture.  You can
implement TCP/IP as a part of the kernel, as a STREAMS module, or even
as an application program, and the only thing that really matters (for
interoperability) is whether the bits on the wire follow the standard.

What would be the value of setting an interface standard that is
either (a) so vague that nobody can follow it exactly and nobody can
port to it and hope to have an interoperable implementation or (b) so
precise that it works only on a tiny subset of all systems out in the
real world and thus can't be used by interoperable implementations?

What bothers me more about this charter is that it seems to assume
that wireless links have requirements that are somehow novel for
IP-based systems.  This is essentially false.  Thus, not only is this
something that the IETF can't solve, it's very likely to be something
that the IETF doesn't have to solve.  Those who know how to build
robust systems will continue to do so, those who do not, will not.

Has any work been done to determine how previous generations with the
very same requirements have solved the problems?  What I see in the
draft is a discussion of this chosen solution, but no discussion of
prior art.

-- 
James Carlson, Solaris Networking         <[email-masked]>
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

---

From: Einar Vollset <[email-masked]>
Date: Mon, 10 Jun 2002 16:55:44 +0100

>===== Original Message From James Carlson <[email-masked]> 
=====
>Phil Neumiller writes:
>> [Vern Schryver wrote]
>> > I suppose instead you want your L2 triggers to reach through IP to
>> > TCP to suggest that TCP do or stop doing or otherwise change.  Don't
>> > you know that people have been doing such things for decades without
>> > the let, leave, or hindrance of the IETF?
>>

Einar

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Jun 2002 09:42:48 -0700 (PDT)

Hello,
  For your information, we made a request to ADs and
submitted the charter statement in order to get a BOF
slot at IETF 54 in Yokohama, Japan and waiting for a
reply.
  I suggest that the individual names in this list
subscribe to pilc since pilc mailing list is expected
to be the email distribution list at least for the
moment. This way any future emails can simply be
directed to [email-masked] and most of us would stop
getting duplicate mails.
Regards,

--behcet
--- James Carlson <[email-masked]>
wrote:

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 10 Jun 2002 13:20:14 -0400

Thanks for the lively discussion all...  Just a few more general points and then I will
let somebody else hop in...

Just because standards have worked in certain ways in the past, does not mean they 
need to stay that way.   We are suggesting a rather fundamental change that is bound
to ruffle a few feathers.  There is ALWAYS resistance to change.  So far the arguments
have not shown WHY this topic SHOULD not be at least a BOF.  Remember we just
need some birds.  We have a flock of supporters already. :-)

With respect to something belonging in the IETF or not, I would remind the commenters
to examine the following RFCs.

RFC-894, IP over Ethernet
RFC-2669, IP over cable modems
RFC-2067, IP over HIPPI
RFC-2176, IPv4 over MAPOS 
RFC-1577, IP over ATM
RFC-2143, IP over SCSI
RFC-2734, IP over IEEE 1394
RFC-1209, IP over SMDS
RFC-1088, IP over netbios
... ... ... .. I could keep going for a LONG time... ...  ...

Hmm, do I see a trend here?  Don't you think by now, we could have said that there are
some commonalities for IP over X?   Also, don't you think by now we could have standardized
some of the other half of the protocol?  IP uber alles was nice, but it is a dated concept.  Protocols
flow in two directions, that is both signalling an bearer channels, why must we retain our strictly
top down perspective in the IETF, i.e. IP over X?   "IP binds with X" may be a more mature
perspective.  This gives some respect to X and accomodates X a bit more. 

As far as the bits on the wire is concerned, this is most definitely the most critical issue.  i.e.
how many of them am I getting of those I am supposed to be getting over time period t?  Is this
link broken?  Do I need to send smaller packets?  Do I need to adjust my data rate?  Do I need
to change the channel coding?  Do I need to change the power?    Many wireless devices will
all pretty much have the sames kinds of problems that they need to communicate to the IP
stack and upper lauyers.  I can't build a radio that will support QoS for all IP implementations
unless IP standardizes this bottom half signalling interface.  Then maybe I can attempt it.

Some folks are posting rather alarmist statements like "all of IP will have to  change" and that is
simply not true. Yes, this is a "roots" issue, but what's wrong with that?  Almost everybody that
has worked on IP mobility for a spell has identified L2 triggers as essential to IP going forward.
Our twist here is that we want to make a standardized home for them in the IP underbelly. 
We also want to add a subscription service to the top side.  Some triggers will just terminate
in IP and others will be fanned out to transports that have registered interest (and a rate they 
can specify).  The fact that I get the event is much more important than acting on it immediately.
This is why IP has to become a bit of an event buffer.

Wireless X's are VERY MUCH different than wired X's?  IP needs a bit of a tune up to
better support wireless devices.  It would be really nice if wireless L2s behaved like wires
but they DONT.  If you made them work like a wire then that would be a violation of the
end-to-end principle.  Its better to put decisions about what to do with the link in the users
hands right?

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jun 2002 10:44:57 -0700

Phil Neumiller wrote:
> some commonalities for IP over X? 

There are. They have been defined in the IP RFC; these are exactly where 
IP over X diverges.

>  Also, don't you think by now we could have standardized

Not all of these deal with signalling; many deal with address mapping, 
e.g., which addresses to use for broadcast, multicast, etc., as well as 
how to get around the lack of shared-media broadcasts for portions of IP 
that require it (e.g., ARP, as well as apps built on bcast and mcast).

> has worked on IP mobility for a spell has identified L2 triggers as essential to IP going forward.

The biggest question here, IMO, is whether these are in fact protocol 
signals (as app. open/close are to TCP, in the reverse direction), or 
whether they can be sufficiently performed via application layer 
information (setting packet loss stats in a MIB somewhere).

Is it really IP or a particular routing _protocol_ that will react to 
these signals, or is it a particular implementation only? So far the 
examples (of a single path fading, requiring another path created) deal 
with the statefulness of portions of the path at the link layer; this is 
not part of the IP architecture, and should not be communicated to the 
IP layer. Statefulness is part of many link layers; recovery of links is 
part of those layers (e.g., Sonet, ATM).

So far the only justifications for doing this at IP are:

	a) modularization
		which, although useful, may be impossible because
		it is the link layer that needs repairing, not the IP
		layer, when these signals change

	b) interaction between different links
		granted, this should happen at the IP layer, but
		again presumes there is state at the IP layer that
		needs repairing. it isn't feasible or appropriate
		to use the IP layer to communicate link state between
		two different link layers.

Joe

---

From: James Carlson <[email-masked]>
Date: Mon, 10 Jun 2002 13:48:56 -0400

> RFC-2669, IP over cable modems
  ^^^^^^^^ just a MIB
> ... ... ... .. I could keep going for a LONG time... ...  ...

All of these define what the bits look like on the wire when you use
IP over foo.  The bits are slightly different in each case because of
the vagaries of each L2.

In contrast, the "triggers" proposal changes *nothing* about the bits
on the wire.  The bits remain the same; only the internal design
(perhaps) changes.

> perspective.  This gives some respect to X and accomodates X a bit more. 

This is the problem.  IP doesn't define any signaling at all, and this
draft seems to assert that it ought to.  I'm not sure that this
definition would be useful enough to be worth the effort.

If it does, then it needs a much deeper treatment than "IP binds with
X" -- it needs some description of how it actually interacts with
transports and (of particular importance) routing protocols.

In any event, such a description still doesn't rise to the level of a
protocol.  Nothing outside of the system in question can see it.  Why
standardize it in the IETF where such external protocols are normally
standardized?

> how many of them am I getting of those I am supposed to be getting over time period t?

I'm afraid you may have misunderstood at least what I was writing.

The "bits on the wire" phrase is a reference to the actual signaling
bits (the 1's and 0's) and the meaning of those bits on the wire.  In
other words, protocols.

I don't see that this draft is talking about protocols at all.  In
particular, suppose we have one system that uses ad-hoc methods to
determine when and how to signal the local IP *implementation* about
link usability, and another implementation that follows the standard
as set by this to-be-written draft.  Suppose that the ad-hoc
implementor is smart enough to make his implementation as "fast" the
other, by whatever definition of "speed" you choose to use.  Do these
two things interoperate or not?  Is the difference between them
externally visible?

If they do interoperate, then we're no longer talking about bits on
the wire.  We're talking about implementation features.  I think that
it's at best dangerous to standardize implementation features because
of the quite obvious problem of tilting the interoperability playing
field towards one vendor or another.

Given that the changes make no observable difference, how does it
matter?

> Is this

Granted; there are all sorts of proprietary issues with each L2.
That's still an implementation issue: how do you design a system such
that the necessary information gets from IP down to the bare metal?

It's no different from the *large* number of IP-to-OS issues that need
to be solved in any real system: how does IP allocate memory when it
needs to?  How are statistics kept?  How is debugging enabled?  How
are CPUs identified to aid in keeping caches hot?  And so on ...

> This is why IP has to become a bit of an event buffer.

That sounds like an interesting system architecture.  However, it's
still not a protocol.  It's a system architecture.

> end-to-end principle.

Nobody is suggesting that.  What I'm suggesting is that the features
of wireless listed here (fast up/down notification, in particular) are
not at all novel features in the world of IP.  There are many systems
out there that deal with millisecond-scale notification for (for
example) SONET.

The suggestion in the draft is that *somehow* IP doesn't deal properly
with this.  I'm disputing this, and I'd like to see a response that
refers to the problem in the established protocol itself, and doesn't
refer to a particular (and flawed) implementation.

>  Its better to put decisions about what to do with the link in the users
> hands right?

I don't think it's a good thing at all to fix implementation flaws by
adding new standards.  If the problem is that there are
implementations that don't get the existing standards right, what hope
is there to improve things by adding yet more standards documents?

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 10 Jun 2002 14:52:59 -0400

Hi James,

I had to respond to this...

> on the wire.  The bits remain the same; only the internal design

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.  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.
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.  How can the IETF EVER hope to build QoS if it continues
to limit itself to this limited method of specification?   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.
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.

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!!! :-)

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 10 Jun 2002 17:23:06 -0400

> On Mon, 10 Jun 2002, James Carlson wrote:
> 
> 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.  QoS 
affects the temporal aspects of IP but not the bits.   Both topics are
of great interest to the IETF and Internet community.   I think this argument
about bits on the wire is getting a bit too pedantic / pedagogical.  The IETF
is what people bring to it (and what the IESG allows of course! :-).

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 10 Jun 2002 22:15:30 +0100 (BST)

Yet TCP congestion control specifies the behaviour that sends bits on
the wire, and it's crucial to the operation of the internet as we
know it.

Similarly, L2 information can be an valuable input to that behaviour,
and influences the behaviour of bits sent on the 'link', even if it
doesn't change the bits per se.

L.

The IETF was not right to standardise congestion control, whose
development should have been left to more efficient global market
forces.
-- a logical conclusion drawn from applying The Economist's
   in-hindsight party line to networking.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: "Mc.Ky" <[email-masked]>
Date: Mon, 10 Jun 2002 18:57:34 -0700

> wireless Jedi will follow me!!! :-)
Sorry - WRONG.
I would suggest you people study what the "packet radio community" has
implemented many years ago. 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!
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.

IP delegated these tasks to TCP - but TCP suffers from the fact that it does
not get any information what happened inside the network, so it has to
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.

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.

Just my 2 cents.....

--Horst Clausen
(New Mexico Tech/Univ. Salzburg)

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 11 Jun 2002 20:45:04 +0900

Hi

Few will doubt that it is useful for the link layer to be able to send event notifications up to IP 
layer, 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. 

But what if the link layer and the IP layer are in separate systems? 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. 

This is an example. When a mobile node changes its point of attachment, it should find its new 
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)'. 

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? 

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.

JinHyeock

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 11 Jun 2002 08:18:31 -0400

Hi,

> implemented many years ago. 

OK.  I have been a ham for 27 years (WB9SML, now N9FCW).  I have used
AX.25 and TCP over packet radio for almost as many.  I am great admirer
of Phil K who frequencts this list.  Nevertheless, this "packet radio" stuff was
great back in the early 80s!  Today's radios are DSSS with huge bandwidths
and incredibly  capabilities that are VERY poorly harnessed by the IP community
and mostly completely wasted.  

> And this has significantly influenced the design

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.  Why is
it hard to do?  Because the IETF has become pompous and monolithic and 
slow to change.  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????

> 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!
> not get any information what happened inside the network, so it has to

EXACTLY!!!!

> in this respect I like the ISDN Refernce model which has separate "planes"

...and these issues with TCP are complained about bitterly in the various
transport WGs.  Isn't the solution becoming obvious???

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

quod erat demonstrandum

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 11 Jun 2002 08:28:23 -0400

Hi JinHyyeock,

----- Original Message ----- 
From: "JinHyeock Choi" <[email-masked]>

> But what if the link layer and the IP layer are in separate systems?

If we use the "bits on the wire" philosophy elaborated on earlier, it should
not matter.  If the bits are defined, they can be sent over any interface to
IP.  The ideal interface would be a function call interface like the 
sockets interface but this is not absolutely necessary.

> What if the link layer in one 
The L2 can put the info into a meta packet that is destined for IP rather than
through IP.  The IP layer can support a functional interface and a meta-packet
interface.  Either way, this WILL HAVE to be implementation specific.

> 17.txt)' 7.5 and 'IPv6 Fast Router Advertisement
> (draft-mkhalil-ipv6-fastra-00.txt)'. Because 

In my heart of hearts, I believe in IP over everything.  If you are referring to 
the IEEE 802 style APs, I belive they are not properly designed.  They should
be IP routers, not simple bridging access points.  I am not out to change the
world.  I recall that IEEE 802 TG F has produced an IP based handover
recommenation that could perhaps be modified to support this in a more IP 
friendly way.
> performance. Did IETF provide input for 3GPP? 

I will let somebody else answer this.  I believe so.
> 3) Is it appropriate to work on L2 trigger in IETF WG?

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.  Why?  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.

---

From: 이지훈 <[email-masked]>
Date: Tue, 11 Jun 2002 21:26:44 +0900

Up to now, IP over any link layer scheme has been providing many problems and solutions (e.g., in IP over ATM, “classical IP over ATM”, MPLS). From the view of network performance, I think that what the responsibility for any solutions are delegated to higher layers (eg., wireless TCP) and link layer (in IP over ATM, ATM), is to set limits by itself to the interworking with some link layers. Similar problems happen in TCP over Wireless environments. If some modifications happen in only host or access router, isn’t it possible to settle the problems? 

Needless to say, all what I say is to set ‘secure L2 trigger’ forth as a premise. Moreover, if IP protocol (RFC791) is not modified, I think L2 trigger is worthy of considering as one solution to IP over any Wireless. 

by Jihoon Lee

---

From: Chip Elliott <[email-masked]>
Date: Tue, 11 Jun 2002 09:22:14 -0400

Just a quick followup. Indeed, the first "Internet" was in the
70s and consisted of the ARPANET, packet radio net (wireless),
and satellite network (wireless). Not to say that IP is entirely
hospitable to wireless, particularly TCP, but wireless has been
there since before the beginning.

Chip Elliott
Principal Engineer, BBN

---

From: Kamesh Medepalli <[email-masked]>
Date: Tue, 11 Jun 2002 11:13:13 -0400

In general, it is a good idea to enhance the IP layer to include input from
L2 (I do not want to get into the issue of whether it has to be a standard
or just an implementation choice). However, the real benefit of changing IP 
routing based on L2 triggers is not clear for 3G systems. I would imagine it 
is more beneficial for the Ad-Hoc systems. 

Could one of the proponents of this issue refer me to any work that quantifies
the merit of such a scheme for 3G and/or Ad-Hoc systems?

For the 3G systems (CDMA2000/UMTS) you would most probably terminate the
IP connection at the PDSN/GGSN (more like HA in Mobile-IP) and then run
a PPP link to the Mobile. Now, handoffs are done much further away from
PDSN/GGSN and clearly, the latency is too much for us derive any benefit
from any L2 info. Even if you do have that info fast enough, you cannot
do much at IP layer since the Radio Access Network works some-what like a 
circuit. You do not perform any routing to the Mobile beyond the PDSN/GGSN. 
You just tunnel the PPP frames through GRE, GTP etc. 

In case of evolutions to 3G (1x-EV-DO, 1x-EV-DV and HSDPA)
you anyway have fast link adaptation and fast cell site selection. Both
of these work below the IP layer to maximize radio channel efficiency.
Again, the benefit of L2 triggers to IP is not clear. If you have a
100% IP based RAN where the base stations also have IP addresses, I can
see L2 triggers becoming more beneficial..again given the time-scales
(can be as small as 1-2ms), I doubt if there is any advantage in changing
the routing functionality that fast. It may just be best done at L1/L2 as 
is currently being done.

I am curious about any work performed in this area...

Thanks,
Kamesh

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 11 Jun 2002 13:40:58 -0700

> is useful. We found some technical problem can be solved more easily with
L2 and L3

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.

We have laid out the need for this type of information on the access router
in http://yegin.org/ietf/draft-manyfolks-l2-mobilereq-01.txt. Any system
that
separates the access point from access router would need a transport
for carrying link-layer event information. Similarly on the client side, if
wireless
client (e.g., laptop) is separated from wireless access device (e.g., cell
phone)...
I'm currently working on drafting such a protocol.

alper

---

From: "Mc.Ky" <[email-masked]>
Date: Tue, 11 Jun 2002 18:32:18 -0700

> and mostly completely wasted.
SORRY again - I wasn't referring to the Amateur Packet Radio but to the
ARPA - Internet
Packet Radio developments.

---

From: "Mc.Ky" <[email-masked]>
Date: Tue, 11 Jun 2002 18:53:08 -0700

.....snip
> and mostly completely wasted.
I said this already - I did not mean the amateur PR stuff but the ARPA PR
development
which was quite another thing - including spread spectrum and high mobility.

> marvelous Internet, can we get on with improving it finally????
IP IS NOT PERFECT!  - sure but that also goes for many other widely deplyed
systems.  As Alan Perlis(?) once said about Fortran "it is not a flower but
a weed -
and it grows in every computer!

> 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".
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.
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!

> handover, mobility, routing, and QoS is the feedback loop, i.e. L2
TRIGGERS!!!
Again - is it the IETF or some other body who should do this.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Jun 2002 08:36:07 -0700 (PDT)

Hello Kamesh,
  
--- Kamesh Medepalli <[email-masked]> wrote:
.... 
> You just tunnel the PPP frames through GRE, GTP
etc.> 
> I am curious about any work performed in this
I can probably refer you to NTT-DOCOMO USA labs recent
work on this. In collaboration with Motorola, they
experimented in implementing Mobile IPv4 fast handover
draft which contains L2 Handover triggers. I think
that Motorola implemented the triggers on a CDMA2000
1X RTT radio and PDSN and they used it to get some
benchmarks of handover. 
  Recently James Kempf made a presentation at IPCN02
in Paris and his presentation can be found at:
http://www.mplsworld.com/ipcn02/
look for James Kemp's presentation here.
  Also we wrote a paper which appeared at IEEE
Communications Magazine's May 2002 issue on how L2
triggers including paging triggers can be implemented
using CDMA 2000 entities.
  Yes you are absolutely right on your assessment that
the benefits in real-time gains would probably be
minimal which suggests looking for better radio
architectures and ways of having Mobile IP function
closer to the base station in public cellular networks
is needed.

Regards,

--behcet

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Jun 2002 09:05:35 -0700

Kamesh,

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.

Ultimately, radio protocols that are a better match for IP are necessry
(so called 4G protocols). Flarion's flash OFDM is an example.

            jak

----- Original Message -----
From: "Behcet Sarikaya" <[email-masked]>
To: "Kamesh Medepalli" <[email-masked]>; "Phil Neumiller"
<[email-masked]>
Cc: <[email-masked]>; "JinHyeock Choi"
<[email-masked]>; "James Carlson"
<[email-masked]>; "Einar Vollset"
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Vernon Schryver" <[email-masked]>
Sent: Monday, June 17, 2002 8:36 AM
Subject: Re: [pilc] What's the benefit of L2 Triggers in 3G/Ad-Hoc
systems ?

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Jun 2002 13:27:38 -0700

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

> > 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 wire?
> > 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
> 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.
>
> I don't see how that's a protocol issue.  It's a design issue.  The
> two are quite different.
>
> 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:
> 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:
> > 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:
> > layer,
> Right; no disagreement there.
>
> > especially for fast handover in wireless environment. And if the
link layer and the IP layer
> Sure.
> 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.
>
> 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.
>
> 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?
>
> You're talking about two things, I think.  802.11 emulates an
> Ethernet, and 3GPP is using PPP.
>
> In my opinion, all of those are negative.
>
> Phil Neumiller writes:
> > 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
> > 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
> I've yet to see a proposal that helps.
>
> 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.
>
> 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.
>
> L2 triggers so far just talk about link up/down.  Where, exactly, is
> this feedback loop?
>
> Phil Neumiller writes:
> > 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
> 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:
> Yes.  This is really an 802 problem, and it should be addressed there.
>
> Mc.Ky writes:
> Right.  It's exactly this that I'm hoping we can avoid.
>
> 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.
>
> 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:
> 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.
>
> --

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 17 Jun 2002 14:55:14 -0600 (MDT)

> From: "James Kempf" <[email-masked]>
> To: "James Carlson" <[email-masked]>,
>    "Phil Neumiller" <[email-masked]>,
>    "Lloyd Wood" <[email-masked]>,
>    "JinHyeock Choi" <[email-masked]>,
>    =?iso-8859-1?B?wMzB9sjG?= <[email-masked]>,
>    "Alper E. YEGIN" <[email-masked]>, "Mc.Ky" <[email-masked]>,
>    "Behcet Sarikaya" <[email-masked]>
> Cc: "Einar Vollset" <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>,
>    "Vernon Schryver" <[email-masked]>,

(I've somewhat trimmed that list of addresses,  perhaps too much
and also perhaps too little.  As someone else said, you guys really
ought to just subscribe to the mailing list instead of forcing
everyone else to get two or more copies of everything.))

> implemented for a particular layer 2..

So what?  It is also silent about many other implementation issues that
cannot be detected on the wire or tested for standards conformance.

> over a particular layer 2. These types of RFC are very specific to a

Yes, and those explicit details are visible on the wire and can be
tested for standards conformance.

> Both of these are standards track RFCs.

Yes, because they specify behavior that is visible outside of the box
and that can be tested for conformance.

> different from the existing cases.

He repeatedly stated the primary characteristic.  It is that the
behavior that the standard claims to be standardizing must be visible
outside of the box.  Any characteristic that cannot be deduced by
watching the wire is outside the realm of standards track RFCs.
An RFC that talks about behavior that cannot be tested is merely so
much hot air.

If you care about standards, you should be concerned about "compliance."
If you handed a prototype 3G phone to an independent testing lab, you
could not hope to receive a "Certified" label or a list of defects
for your L2 triggers standard.

No, a vendor's swearing, hoping to die, crossing its heart that it
really has followed the standard is not even hot air.

---

From: James Carlson <[email-masked]>
Date: Mon, 17 Jun 2002 16:56:58 -0400

James Kempf writes:
> 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

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.

> over a particular layer 2. These types of RFC are very specific to a

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.

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

---

From: James Carlson <[email-masked]>
Date: Mon, 17 Jun 2002 15:21:06 -0400

What wire?

> especially for fast handover in wireless environment. And if the link layer and the IP layer 

Sure.

Huh?

True.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 17 Jun 2002 15:00:32 -0700

>           bridged media, which is clearly where the hardest problem

Yes. This is where L2 triggers require a "protocol." A protocol 
between a wired-to-wireless bridge and an attached host is required
to communicate certain L2 events (link down, link up, ..) to
the interested parties. Please see 
 http://yegin.org/ietf/draft-manyfolks-l2-mobilereq-01.txt for consumers
of such a protocol, and types of L2 events they are interested in.

alper

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 18 Jun 2002 14:58:32 +0900

> as a special proprietary hack.

I think it has something to do with IP. The recipient of, for example, L2 reachability 
information is L3 entity. Hence that information must be represented in IP format in 
order to be understood by receiving L3 entity. Hence, we should define IP message
format for that information, for example ICMP or extension header. Moreover, we 
may need L2 trigger transport protocol, too. 

> Ethernet, and 3GPP is using PPP.

I guess my expression is not clear enough. I mean, it will be nice to provide technical 
input to other standard bodies just as IETF provided technical input to 3GPP. 

> In my opinion, all of those are negative.

I don't understand. You agreed that it is useful for the link layer to be able to send 
event notifications up to IP layer like below. 

>Right; no disagreement there.

Doesn't above mean that at least you agree to 1)?

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 18 Jun 2002 05:42:46 -0400

It appears that it was a bad idea to put a BOF discussion on an existing WG list.  We
are getting way to much noise from the peanut gallery.  Can anybody suggest a list
or host a list for the L2  triggers BOF so that interested parties can have a friendly
discourse without getting pilcers up in arms?   BTW, everyone will be welcome to the
new list.  I just want to avoid drive by sniping at the BOF discussions.  I also want
to encourage people to speak up without feeling shut down by uninterested parties.

Thanks,

Phil

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 18 Jun 2002 08:47:29 -0600 (MDT)

> From: "Phil Neumiller" <[email-masked]>
> To: "Vernon Schryver" <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, "Behcet Sarikaya" <[email-masked]>

> to encourage people to speak up without feeling shut down by uninterested parties.

If you really need an official mailing list for a discussion among one
or two dozen people and don't have your own SMTP server, you might try
one of the free mailing list outfits.  I've heard http://groups.yahoo.com/
mentioned most frequently.  It is in a lot of anti-spam blacklists,
because Yahoo allegedly doesn't care enough about its abuse by spammers.
However, that sort of problem often comes with "free."

Interest among prospective authors is necessary but not sufficient
for standards track documents.  If you got a charter approved and a
WG created, any standards track documents it produced would have to
survive Last Call in a pompous peanut gallery of people who have
actually worked on the stuff you propose to standardize and control.
Even an Informational RFC would need IESG approval, although that
would not be a problem.

Again, the reasons I trust there is no hope of a standards track L2
Triggers RFC do not apply to an Information RFC.  As has been said
repeatedly, an Informational RFC on L2 triggers could be valuable.
Why are you so set the standards track?

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 08:03:32 -0700

> cannot be detected on the wire or tested for standards conformance.

One possible use for L2 triggers may be as a similar set of requirements
on wireless Layer 2 for implementing better performing Mobile IP
handover. Such requirements would not be standards track, but purely
informational. As such, they would not be involved in tests for
standards conformance or detection on the wire, but purely for helping
designing Layer 2s that better fit IP. This would be similar to the
requirement in RFC 2460 for path MTU handling.

Without such a document, it is difficult for standards bodies, such as
3GPP and IEEE, to know what they need to do to make their protocols a
better fit for IP. Of course, this can be handled on a case by case
basis, as it is now, but documenting some IETF concensus on what makes a
good wireless Layer 2 handover would make the task easier.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 08:40:43 -0700

> function calls, system calls, or just about anything you care to.

If you look at "Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications", ANSI/IEEE Std 802.11
1999-00-00, there is defined in Section 7.2.3 .6 the reassociation
management frame format. This is sent between the host and the access
point when the host reassociates with an new access point upon handover.
As such, it is verifiable for standards conformance.

Similarly, 802.11f, "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across Distribution
Systems Supporting IEEE 802.11 Operation," draft January 2002 (IAPP),
describes an IP-based protocol that is sent between access points when a
host reassociates. As such, it is verifable for standards confromance.

Currently, the interaction between these and the Mobile IP protocols
defined in draft-ietf-mobileip-fast-mipv6-04.txt and
draft-ietf-mobileip-lowlatency-handoffs-v4-xx.txt (now expired) is
undefined. In fact, if you take a look at these protocols, it becomes
difficult to see how they could contribute to improving Mobile IP
handover performance, given the typical 802.11 network of bridging
access points connected up to routers. In fact, for IAPP, the net effect
on Mobile IP handover looks like it might be fairly negative.

A similar case can be made for Bluetooth. Referring to Brent Miller's
book, Bluetooth defines IP as running over PPP. As for handoff
performance, the amount of time required to establish a link between a
Bluetooth piconet master and slave looks like it would be on the order
of seconds, effectively ruling out any high performance Mobile IP
handover.

One of the hypotheses (developed by talking with some people active in
the 802.11 development) is that if the 802.11 committee and Bluetooth
SIG had had a set of requirements for supporting high performance Mobile
IP handover, they might have had an easier time defining their Layer 2
protocols to be more Mobile IP handover friendly. So one possible task
for a Layer 2 triggers working group is to define those requirements.
Such a document would not be used for standards conformance testing, but
just as an informational document for other standards bodies that need
guidance.

Another possiblility is to define "Mobile IP Handover over 802.11", in
which the wire format for the interaction between Mobile IP and a fast
handover protocol between the briging access point and the router would
be defined, that would be appropriate for standards confromance testing.
At the moment, this is not an option, since the 802.11 committee does
not have the right Layer 2 protocol to effectively provide the optimized
handover information to the router, though it might be possible to
define in the context of an extension to IAPP. Similar documents would
be needed for other wireless protocols, of course, as has been done for
IP over the wire.

A final option, on which there is currently some work, is an ICMP
message that would allow an access point to inform a router that a new
host has appeared (or an old one disappeared). This could also be used,
for example, between an Ethernet switch and a router when the switch
received a 10BaseT electrical signal that a new host appeared or
disappeared.  As such, it would have applicability beyond wireless.

Do you think these possible tasks are valueless?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 08:47:27 -0700

Vern

> Why are you so set the standards track?

I don't think anybody is set on standards track at this point. The
reason for doing this as a WG rather than an individual effort is to get
IETF concensus on it, so that it would represent the best thinking of
the IETF to other standardization groups, like IEEE, on what's needed
for a high performance wireless Layer 2 for IP.

            jak

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 18 Jun 2002 11:53:31 -0400

I absolutely disagree.  IP will have to change for modern wireless devices.  Those who say
it won't have their head in the sand.  James we are not taking the PILC approach of creating
a recommendation for L2 providers.  We are a bunch of L2 providers telling IP what it 
needs to do!!! Absolutely has to be standards track.

---

From: James Carlson <[email-masked]>
Date: Tue, 18 Jun 2002 12:02:29 -0400

> As such, it is verifiable for standards conformance.

That's 802.11.  That's not plain old 802.  If you have an Ethernet
bridge in the way, then you're sunk.  That's the problem I referred
to.

> host reassociates. As such, it is verifable for standards confromance.

Personally, I think it's a terrible mistake for these devices to use
an IP-based protocol for this purpose.  802 is (currently) agnostic
with respect to network layer protocols, and I think this is a very
good property.  In particular, 802 defines a family of Spanning Tree
messages used to eliminate loops in an 802 network.  These are,
naturally enough, not based on IP.  I see no reason that this related
feature should be a special thing that only IP can use.

What happens if I'm running OSI over my 802 network?  Such a thing is
not completely unheard of.

What happens if I *don't* want to give my bridges separate IP
addresses?  What are the security implications?  What security
protocols are defined for this exchange?

Fortunately, this is an IEEE issue, not an IETF issue, unless the
proponents of this protocol want to introduce it to the IETF as an
I-D.

> access points connected up to routers.

Yes.  However, it's a general 802 problem.  The fact that it bothers
some people in particular for this one application doesn't mean that a
special solution for this one case is warranted.

> In fact, for IAPP, the net effect

Really?  In that case, something is horribly broken.  There's nothing
at all in PPP that gives you such an absurd link establishment delay.
If it takes you more than 4 or 5 round-trip-times to establish a PPP
link (typically an order of milliseconds for most *usable* link
technologies, not seconds), then you have some serious implementation
bugs to worry about first.

> just as an informational document for other standards bodies that need

Requirements documents are never standards-track.

> be defined, that would be appropriate for standards confromance testing.

If this is done, *please* address the general problem: notification of
remote L2 failure in 802-based protocols.  Solving the problem for one
particular case is (in my opinion) a very bad thing to do.

> disappeared.  As such, it would have applicability beyond wireless.

Fortunately, that message already exists, at least for IP: see RFC
1868.

It's not ICMP, though.  Is that a necessary feature?

> Do you think these possible tasks are valueless?

Some appear to me to be so, but that's quite beside the point.

The point is whether or not these things actually belong in the IETF.
I don't think that the IETF owns the IEEE protocols, nor that the IETF
should set out to modify the IEEE protocols.  IETF participants who
have particular 802-related hobbyhorses certainly ought to be involved
in the IEEE to get those protocols changed to taste.

---

From: James Carlson <[email-masked]>
Date: Tue, 18 Jun 2002 12:19:15 -0400

Phil Neumiller writes:
> it won't have their head in the sand.

Is it at all possible to keep this on a technical level?  As one of
these people, I don't think that the people who disagree with you can
fairly be characterized as having heads in the sand.

>  James we are not taking the PILC approach of creating

Then that's clearly a problem.  I can see no IETF standards-track
material to be created here.

The good news is that, since you're L2 providers, you have a handy
place in which you can push these demands: the standards bodies that
are in control of those L2 technologies of interest.  The IETF has
control over PPP, and if any changes were needed there, that can be
done.  The IETF doesn't have control over Ethernet, 802.11, Bluetooth,
3GPP, or any of the other L2 technologies under discussion.  How can
the IETF write standards-track documents that change how those L2
technologies operate?

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 18 Jun 2002 10:36:36 -0600 (MDT)

> To: "Vernon Schryver" <[email-masked]>, <[email-masked]>,
>    <[email-masked]>, <[email-masked]>

> for a high performance wireless Layer 2 for IP.

I thought working groups could produce Informational RFCs. 
Consider RFC 2135.
See also http://www.ietf.org/html.charters/pilc-charter.html

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 18 Jun 2002 12:53:10 -0400

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.

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.  In order for this to
happen in the correct way, the IETF needs to specify it.

What is so complicated about this?   Just because we proposing something new, i.e. it
does not exist in ppp, arp, or other similar mechanisms why is it immediately assumed
that it is an L2 issue?

The IETF has already made their recommendations to L2 providers.  Now its time for
the IETF to be a bit more introspective.  If there are some skeletons here, let's pull them
out and take a peek.

---

From: James Carlson <[email-masked]>
Date: Tue, 18 Jun 2002 13:10:26 -0400

> A).  IP needs to create a standard interface method on its unspecified bottom half.

No, unless it describes a protocol, it doesn't.  Such a method would
either have to be really vague ("needs some way to send one or more
packets") or would have to be dependent on system architecture.  If
it's really vague, then it's at best an Informational document, though
I don't see the purpose.  If it's dependent on system architecture,
then it doesn't belong in the IETF.

> B).  It already has one on the top, namely sockets.

Note that sockets are not an IETF standard in any way.  (Yes, some
documents do have references to them, but I think this is much more
"bug" than "feature.")

Note also that *many* systems have non-sockets ways of accessing IP --
including TLI.  The IETF doesn't standardize software interfaces and,
as I've said before, is ill-equipped to do so and ought not do so.

This is what groups like X/Open do for a living.

> happen in the correct way, the IETF needs to specify it.

I don't see how that can actually be done.

> does not exist in ppp, arp, or other similar mechanisms why is it immediately assumed

The problem is that it's not externally visible.  I don't think it can
be specified in any terms that will make sense in an architecture-
neutral form.

> the IETF to be a bit more introspective.  If there are some skeletons here, let's pull them

I think the recommendations are exactly the right vehicle here.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 10:19:18 -0700

Phil,

*What*, precisely, do you propose be standards track? The current draft
defining abstract L2 triggers or something else?

I do think Vern and James have a point about the necessity of standards
specifying something on the wire that can be verified for conformance.

            jak

----- Original Message -----
From: "Phil Neumiller" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Vernon Schryver"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 18, 2002 8:53 AM
Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

> To: "Vernon Schryver" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 10:25:24 -0700

> See also http://www.ietf.org/html.charters/pilc-charter.html

Yes, that's true.PILC is an example as you say.

            jak

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 18 Jun 2002 13:52:01 -0400

Something else.  The BOF is taking a different track.  Please read the archives on pilc regarding BOF.
----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Phil Neumiller" <[email-masked]>; "Vernon Schryver" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, June 18, 2002 1:19 PM
Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 11:00:37 -0700

> protocols are defined for this exchange?

Agreed, particularly with the security issue. Some of their proposals
for security would be massively suboptimal for Mobile IP handover.

> special solution for this one case is warranted.

The problem with this particular application is that there is some
desire on the part of hardware vendors and service providers for a
standard so that the handover time can be reduced for VoIP and other
realtime media. As is usual in standards work, there is a need for an
interoperable standard to facilitate products. Most of this need is
being expressed in the 802.11 committee, but the technical clue about
what works for MIP resides in IETF, IMHO.

> bugs to worry about first.

It doesn't all have to do with PPP (though there is an issue of
transferring PPP state on handover that is common with other wireless
protocols that use PPP, like 3GPP2). For VoIP applicaitons, L2 and L3
handover must complete within 40 milliseconds.

> Requirements documents are never standards-track.

Agreed.

> particular case is (in my opinion) a very bad thing to do.

Possible, but there are very specific requirements on wireless handover
involving information that must be made available. These might not apply
in the general case. But this is an issue for IEEE and not IETF, as you
mention later.

> It's not ICMP, though.  Is that a necessary feature?

RFC 1868 won't work for handover. The new access point must also provide
the MAC address (for 802.11) of the old access point.

In addition, there's also a need for this kind of signaling in IPv6,
hence the interest in ICMP. An extension to ARP might be acceptable for
IPv4, however. This could be a topic of discussion for the BOF/WG.

> in the IEEE to get those protocols changed to taste.

I quite agree that the IEEE (or 3GPP for that matter) work should be
done in IEEE (or 3GPP). The issue seems to me whether:

a) The IETF is the right place for a non-standards track requirements
document embodying IETF concensus on what is needed for fast Mobile IP
handover from Layer 2 for future designers of wireless link protocols,

b) Whether there is need for some form of standard IP protocol (ICMP,
ARP extension, other?) to provide a non-L2 specific way of providing
this information.

            jak

---

From: Dan Grossman <[email-masked]>
Date: Tue, 18 Jun 2002 14:05:25 -0400

> happen in the correct way, the IETF needs to specify it.

There are two sets of issues here:
1) What are the semantics the need to be passed up the stack, and how are they to be used at each
layer in the stack; and
2) What APIs should be used to pass those semantics

I think that most of the objections are to the IETF working on (2).  Frankly, I'm sceptical as to the
value of (2) myself, and certainly think that X-Open and like organizations are the place to do that
work.

As to (1), you are making the case that  packets on the wire are not the only stimulus that modifies
state in, or causes output from, the layers in the IP stack*.   If it is your interest to "look for
skeletons" vis a vis operation of IP in a wireless environment, then cataloging those things at a
semantic level is a useful exercise.

* Although the IP forwarding process is nominally "stateless", it has trivial, transient state.
Forwarding tables, routing databases, filter tables and the like are also state information and occur
at the IP layer.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 18 Jun 2002 14:28:28 -0700

Phil,

> Something else.  The BOF is taking a different track.

You mean "defining an internal interface between IP and link-layers?".
This is clearly different than what I had in my mind when proposing
this bof. I see benefits of defining such an interface, but I think more
immediate problem that needs to be tackled in IETF is a transport
protocol for carrying L2 triggers. This is essential in bridged networks.
A simple client-server protocol to convey L2 events from bridges
to hosts is needed. I'm currently working on a draft defining such a
protocol. I should be able to publish it in a week. And I think that
would be a candidate for standards-track.

> Please read the archives on pilc regarding BOF.

alper

> To: "Phil Neumiller" <[email-masked]>; "Vernon Schryver"
<[email-masked]>; <[email-masked]>;

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 18 Jun 2002 15:40:14 -0700 (PDT)

Hello,
  Alper: thanks for your drafts. Please note that our
BOF application has not yet been accepted.
Maybe I should write lots of drafts and submit to PANA
(just a joke).
  Spencer: if you do not mind keeping L2 Trigger
discussions on pilc mailing list then we should
continue using pilc. If there is a problem, then maybe
we can host a new mailing list.
  Phil: your idea is unique and it may be worthwhile
considering but only with a draft.
  Regards,

--behcet
--- "Alper E. YEGIN" <[email-masked]> wrote:
> > To: "Phil Neumiller"
> <[email-masked]>; "Vernon Schryver"
> > > > I absolutely disagree.  IP will have to change
> for modern wireless
> > > devices.  Those who say
> > > > it won't have their head in the sand.  James
> we are not taking the
> > > PILC approach of creating
> > > > a recommendation for L2 providers.  We are a
> bunch of L2 providers
> > > telling IP what it
> > > > To: "Vernon Schryver"
> > > > > > Again, the reasons I trust there is no
> hope of a standards track
> > > L2
> > > > > reason for doing this as a WG rather than an
> individual effort is to
> > > get
> > > > > IETF concensus on it, so that it would
> represent the best thinking
> > > of
> > > > > the IETF to other standardization groups,
> like IEEE, on what's
> > > needed

---

From: "Jihoon Lee" <[email-masked]>
Date: Wed, 19 Jun 2002 19:49:47 +0900

> may need L2 trigger transport protocol, too. 

I think that the (unified) mapping rules are also needed.

That is, the mapping rules include the relation of L2 information to L3 information.

For example, in mobile QoS support, the information for Binding update with QoS parameters has been defined.

Equivalent to the mapping of L2 QoS parameters to L3 parameters, the mapping rules for L2 triggers must be defined to provide fast and QoS mobility.

> input to other standard bodies just as IETF provided technical input to 3GPP. 

This is the time IETF has to start coworking with the other standard bodies.

---

From: "Phil Neumiller" <[email-masked]>
Date: Wed, 19 Jun 2002 09:10:29 -0400

The more drafts the better.  I had not gotten the notion that "my" idea was
"unique".  From personal mails I have received and discussions that are logged
there is at least some support.  Perhaps this is a different BOF though?   The
L2 triggers BOF appears to be content to make recommendations for
L2 providers.  Is this correct?

My two cents on this, is that the IETF is not really in a position to affect
change in L2 standards bodies this way.  By way of contrast, if the IETF
provided an RFC that defined a packet (or meta-packet) that an L2 layer 
could send/receive (out-of-band) perhaps to the IP stack, that would be
extremely useful and provide a nice clean solution to the L2 triggers issue.
Even if the IP layer simply provided a reflector service for these meta-
packets for subscribed  transports it would add huge amounts of flexibility
that must currently be done in proprietary ways. 

If the IETF wants to stay vague about this very simple concept that is
OK too, and I will show deference to general consensus.  I felt it was
important to express my thoughts (and apparantley other folks working
on other L2s have similar thoughts).  Also, since I got somewhat emotionally
attached to this idea (bad idea usually) I must beg for your pardons
for my occassional vitriolic embellishments in my responses.

Best regards,

Phillip D. Neumiller

---

From: James Carlson <[email-masked]>
Date: Wed, 19 Jun 2002 09:41:16 -0400

> extremely useful and provide a nice clean solution to the L2 triggers issue.

Yes, sounds like what you've been advocating all along.  However, it's
still a non-starter: these "meta-packets" would appear only between
the L2 implementation and the IP implementation on a given host.
They're thus not testable or observable outside of that host and are
local design and/or architectural details.

> that must currently be done in proprietary ways. 

Sure.  But it's still a system design issue, and not a TCP/IP protocol
issue.  The former is certainly a fascinating and useful area, and
obviously very important for many (or most) TCP/IP implementors, but
it's just not the focus of the IETF.  IETF documents tend to tell
people what the system must do in order to interoperate, and quite
intentionally leave out *how* it must be done.

A revised version of DLPIv2 that covers these signaling mechanisms in
detail would probably make a number of people happy.

> on other L2s have similar thoughts).

That's the essence of an I-D, and it's certainly the spirit of the
Informational track.  I see no particular need for the IETF to do
this, but since *you* do, you might want to push it along non-
standards track.  (If the idea can't survive outside of the standards
track, then I'm afraid I must not completely understand the issue.)

---

From: "Phil Neumiller" <[email-masked]>
Date: Wed, 19 Jun 2002 10:11:10 -0400

Hi James,

> local design and/or architectural details.

Its ironic that the IETF is more than willing to specify what bits should be
in the payload of an L2 device and on a wire (that they can't directly touch)
but not be willing to communicate with an L2 device (which they can directly
touch) in any standard way.  Over the years it seems that the IETF matured
to the point of almost completely specifying the IP to Ethernet binding.  If
we use the OO concept of inheritance, or design patterns, isn't logical that
one would seek commonalities between L2 to IP bindings and standardize
this?  It seems that just some maturing of the relationship between L2s and the
IP layer is needed here.  For some reason, I think this will eventually happen.
It may take a long while though...
> intentionally leave out *how* it must be done.

Yet inter-operating with multiple L2s is somehow deemed NOT useful?
It is an area that huge amounts of proprietary code is written to do the
same thing over and over again, right?  Some use this as a prototypical example
of software developer pork barrelling.  A whole cottage industry has developed
around the black art of device drivers and their intricate details.  I have even
written a few myself over the years.  This is definitely an underspecified and
under-standardized area of networking art.  Maybe I am way off in the
weeds here.  I think I have expressed my arguments now the best I can.
I think I will be quiet for while.... :-)  We can only hope...

Best regards,

Phil

---

From: James Carlson <[email-masked]>
Date: Wed, 19 Jun 2002 10:34:21 -0400

Phil Neumiller writes:
> touch) in any standard way.

I think you're confusing two very different things here:

	- the documents that are standardized via the IETF

	- the work that folks do to make useful systems

The two are quite different.  Just because people have to do any
number of special efforts in design or implementation of any part of
TCP/IP does *not* make all of those efforts into IETF standards
issues.

The problem is that system designs vary by much more than I (or
probably anyone else on this list) can possibly comprehend.  The IETF
is not a software interface standards group.  It's really not.  There
are many such groups -- X/Open being one that has been cited here
before.  Linus Torvalds perhaps being another.  ;-}

The point is that there's no such thing as One True System
Architecture.  Perhaps, if one is stuck writing software for a
particularly ubiquitous O/S, it might seem that way, but it's just not
true.

Worse still, the IETF's structure is really not set up to handle such
issues.  The IETF (and the IESG) have fair cross-sections of folks who
build IP-speaking devices for a living, but the folks who do system
interfaces for a living don't all participate here.  They're off in
the appropriate standards bodies.

>  Over the years it seems that the IETF matured
> to the point of almost completely specifying the IP to Ethernet binding.

No.  It specifies where the bits belong inside the Ethernet frames.
That's all it can specify.  It doesn't specify whether the hardware
interface is interrupt-driven or polled, whether the driver is single
or multithreaded, whether the entrance to the IP stack is an upcall, a
BSD soft interrupt, or a DLPIv2 STREAMS M_PROTO message.

It doesn't, and I'm arguing that it can't and must not.

>  If
> this?

Seeking the commonality, and documenting the necessary bits and the
known good practices (or at least the possible alternatives) all seem
like mostly good things.  Unfortunately, I see no hope at all of
"standardizing" any such thing.

What external test do you apply to show that some vendor has followed
a design practice?

>  It seems that just some maturing of the relationship between L2s and the

On a given system architecture, this can be done.  The IETF doesn't
just support one particular design philosophy, no matter how "good" it
might seem right now.  Design strategies are passing fads that come
and go; protocols are forever.

> Yet inter-operating with multiple L2s is somehow deemed NOT useful?

Correct.  That's not interoperability.  That's perhaps "system design"
or "code reuse" or "making things easier for third party integration."
It's not interoperability by any stretch of IETF terms.  There's only
one party involved as far as the IETF is concerned; the system itself
is a node on an IP network.  Saying that you ought to be internally
interoperable with yourself is probably axiomatic.

> same thing over and over again, right?

You bet.

>  Some use this as a prototypical example
> of software developer pork barrelling.

Ha!  If only it were that simple!

"Hello, I'd like to put the turbocharger from my wife's V70 on my
325i.  What do you mean I can't do that?  Aren't there any standards
for cars?"

>  A whole cottage industry has developed

Break out the scythe.  ;-}

Unless I miss my guess, you're proposing a standard internal low-level
("kernel") *software* interface (and corresponding assumptions about
system architecture) that'll work on Windows, Solaris, Linux, *BSD,
AIX, VMS, MVS, VxWorks, IOS, and others.  "Weeds" don't come to mind
here.  "Windmills" do.  :-/

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 19 Jun 2002 08:43:30 -0600 (MDT)

> From: James Carlson <[email-masked]>

> detail would probably make a number of people happy.

I bet that besides being unfamiliar with the unhappy history of WAP,
the WAP Forum, and whatever the WAP Forum recently changed into (unhappy
at least from the prospective of people who know that TCP worked always
fine on 9600 bit/sec modems), some people are not aware that "DLPI"
stands for "Data Link Provider Interface."  DLPI already includes
"packets or meta packets" sent among L2 and L3 modules.

See http://www.google.com/search?q=dlpi

There have been repeated demands in this thread that the IETF "work
with" other standards bodies.  The first rule for any bureaucratic
outfit that hopes to work with others is not stomp on other outfits'
turf (at least not accidentally).  For the IETF to write standards in
the Open Group's territory would be seen as an act of war by the Open
Group.  The IETF could say "these are the vague sorts of things that
something like DLPI might communicate," but the actual "meta packets"
must be defined by the committees that own that turf.

And no, an individual's difficulties getting an idea heard by the Open
Group would not be a reason for the IETF to go to war with the Open
Group....or the ITU, IEEE, ANSI, or any other standards group.

>              ...  (If the idea can't survive outside of the standards

No, that an idea cannot survive outside of the standards track only
shows that the idea is seen as wrong or useless by the people who
matter.  The vast majority of the people who matter do not participate
in the IETF, but are the people who read (or don't read) RFCs and
make (non-)compliant products.  The standards track is not about
laws or compelling programmers and hardware designers to write C.
The IETF is powerless to order anyone to do anything and has little
power to persuade.  If an idea is not innately convincing, it's
dead on delivery in an RFC.

The difference between Informational and Standards Track RFCs is
that the former document ideas while the latter document the
consensus of the IETF about an idea the consensus says is good and
also the business of the IETF.  There could be an RFC about world
peace and hunger, but it should not be on the standards track.

---

From: James Carlson <[email-masked]>
Date: Wed, 19 Jun 2002 11:01:57 -0400

> Group....or the ITU, IEEE, ANSI, or any other standards group.

Would you like Frame Relay or MPLS with that?  ;-}

> matter.

No, that's not what I was saying, though I think you're right about
that.  To rephrase my statement in more precise terms:

	"If the advocates of this L2-L3 internal signaling are unable
	to accept writing their proposal into an Informational RFC,
	and they instead require Standards Track or nothing at all,
	then I don't understand the issue with which they are
	dealing."

In other words, why do the advocates think that there _must_ be such a
standard?  I suspect that there's some sort of disconnect here.
Perhaps some other standards body thinks that it can only "rely on"
standards-track documents (yes, I've seen this aberrant behavior
before; "informative references" sometimes cause pain).  Or perhaps
it's merely some bureaucratic regulation enforced by some designer's
employer.  I'm not sure, but I don't see what the issue is.

> peace and hunger, but it should not be on the standards track.

Strongly agree, though that wasn't my point at all.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Jun 2002 12:01:34 -0700 (PDT)

James,
  My opinion on this is not to underestimate the
importance of informational RFCs.
  I checked at IETF's RFC pages and noticed that yes,
you are right most of the APIs defined so far are
informational RFCs (IPv6 API 2292, Service Location
API, etc.). 
  Curiously, the security APIs (RFC 2744 and 2853) are
of proposed standards. I could not see any difference
in the way these APIs are defined, i.e. 2292 and 2744.
  Also let me point out that RFC 3022 which defines
NAT/NAPT behaviour is also informational and this was
what I meant by the first sentence of this mail.
  So what is wrong with informational RFCs that are
needed and have great potential to be used?

Regards,
--behcet

---

From: James Carlson <[email-masked]>
Date: Wed, 19 Jun 2002 15:26:02 -0400

> importance of informational RFCs.

I certainly wasn't.

> in the way these APIs are defined, i.e. 2292 and 2744.

Yes.  As I said before, I think that the rare exceptions represent
bugs rather than features.

> what I meant by the first sentence of this mail.

Sure.  There's lots of useful stuff that's in Informational RFCs.
That's not particularly at issue here.

> needed and have great potential to be used?

Nothing in particular.

What I question here is:

	- Why do some folks think it needs to be on standards track?
          I see no good purpose to that, and a lot of damage that can
          be done.

	- Assuming we focus only on the L2/L3 interface *design*, why
          do we think we can get it anywhere near right for anything
          other than some subset of system architectures?

	- Isn't there a more appropriate standards group to be
          handling these internal system software interfaces?

The first question can be summarized as "if you must do it, make it
Informational."  The other two questions are "are you really sure the
IETF is the right forum?"

I think you might have misunderstood what I wrote.  I wouldn't yell
*too* loudly if someone wanted to publish an Informational RFC on
this.  I'll be happy to ignore yet another thing on Informational
track that I can't actually use.  There are certainly sillier things
published as Informational RFCs.  But if anyone cares what my opinion
on the project is, I don't think it's a terribly worthwhile effort in
that it represents just one (albeit somewhat interesting) aspect of a
substantial software design topic.

So, I get my new Ethernet card, and it says that it conforms with RFC
"L2-Trigger".  Now what?

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 19 Jun 2002 14:17:28 -0600 (MDT)

> From: Behcet Sarikaya <[email-masked]>

> ...

Don't assume that everything done in the IETF is correct even by the
IETF's own rules. 

RFC 2853 is about Java and RFC 2744 seems related.  Java is supposed
to be independent of and portable to almost any system.  You're supposed
to be able send Java programs over the wire and have them work.  That
suggests that conformance testing of black boxes that implment those
standards can be done by plugging them into a network and running
tests.  Mobile phones might need to be "plugged into" a shielded room
or otherwise connected by wireless "wires," but I suspect they could
still be conformance tested.  That would not true of the proposed L2
triggers API particularly for some of the devices that supposedly need
it, mobile phones.

> ...

Who says there would be anything wrong with them?

The IESG will publish any reasonable Informational RFC.  I've argued
for perhaps 10 years that is bad, because it allows and encourages
people to try to steal the IETF's imprimatur.  However, even I
don't see anything wrong with this sort of Informational RFC.

I think James Carlson is pointing out that a better question is what
would be right with it.  Anyone who hopes that an L2 Triggers RFC
would cause code to appear would be disappointed.  You mentioned RFC
2292.  I have a freely distributable package that wants to use IPv6
sockets.  Porting and distributing it has shown that even today, more
than 4 years after RFC 2292 was published, many current and popular
UNIX systems still do not entirely support RFC 2292.  What's more,
RFC 2292 is about an interface with relatively little controversy and
for the restricted set of UNIX-like platforms.  L2 triggers would be
about an area with decades of justifiable controversy and it would
evidently apply to most or all platforms.

The only issue is the insistance on the Standards Track.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 21 Jun 2002 09:31:28 -0700 (PDT)

Hello all,
>> The only issue is the insistance on the Standards
I think there is no insistance on the standards track.

It seems that there is consensus on what we expressed
in the proposed charter which was submitted to IETF in
our BOF application.

There are several drafts:
draft-corson-triggered-00.txt
draft-jinchoi-l2-frd-01.txt
draft-yegin-1-...txt
draft-yegin-2-...txt
that can be discussed at the meeting and that may
serve as the basis for further work.
  It seems that we are all set.

Regards,

--behcet

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 22 Jun 2002 12:41:22 +0900

Hi

We changed our file name to draft-jinchoi-l2trigger-fastrd-01.txt 
(from draft-jinchoi-l2-frd-01.txt) at editor's request. Details are like below.

Title :  Fast Router Discovery with AP Notification
Author(s) :  J. Choi, D. Shin
Filename :  draft-jinchoi-l2trigger-fastrd-01.txt
Pages :  5
Date :  19-Jun-02
URL:  http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt

Our draft deals with 'How can a mobile node find its new access router 
sufficiently fast?' In our proposal AP caches Router Advertisement message 
and sends it to a new mobile node as soon as L2 association is made. 
We present a way for AP to cache necessary RA.

In version 1, we put new chapter (Chp 5) on L2 trigger and formulated 
sending the RA as a trigger like before.

            L2                   Event            Recipient      Parameters
           Trigger
      +-------------+---------------+------------+-----------------+
       |    Fast          |  When new L2 |     MN        |     Router           |
       |   Router       |  association      |                    |  Advertisement  |
       |  Discovery   |    is made.        |                    |                          |

All comments are appreciated.
 
Best Regards

JinHyeock Choi

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 Jun 2002 08:18:09 -0700 (PDT)

Thanks JinHyeock.
There is another draft which is something we should
discuss:
http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt

This draft proposes a L2 Triggers protocol which can
be proposed standard.

  I suggest people read this and comment.

Thx.

--- JinHyeock Choi <[email-masked]> wrote:
> URL: 
http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt
--behcet

---

From: "Jihoon Lee" <[email-masked]>
Date: Thu, 27 Jun 2002 09:03:23 +0900

Hi. Alper E. Yegin.
 
I have some questions about your I-D "Link-layer Triggers Protocol" 
 
1. I agree that UDP-based query/response type's signaling is needed in AP <--> AR part. However, I don't know the reason why UDP-based query/response type in host <---> access device part is required. In the I-D, a signaling is needed between laptop and cell phone in order to identify each other's L2 address and generate the appropriated UDP/IP datagram. Isn't it sufficient for only a simple L2 signal (like the case that host and access device exists in the same IP node) to notify its link status? The relation between host and access device is not changed. I think that a different rule needs to be applied between host and access device. 
 
2. In page 4, there is "A client may periodically send these multicast Hello messages to keep track of active servers". What do you think about the Hello message's interval (i.e., default value)? 
 
3. In page 4, "Each registration has a lifetime and must be renewed before expiration."
For registration renewal, how is the rule applied? For example, host issues a new registration request to refresh these active entries at elapsing 2/3 lifetime. Is it correct?

4. You said "a transport mechanism is needed to convey link-layer triggers". Isn't it sufficient for ICMP or IPv6 extension header/Destination option header to convey L2 triggers?

5. UDP/IP datagram is constricted to 255 TTL. However, I think if a host moves to another AR's boundary, TTL value will decrease. What do you think about?

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 27 Jun 2002 15:55:30 -0700

Hello Jihoon Lee,

> 1. I agree that UDP-based query/response type's signaling is needed in AP
<--> AR part. However, I don't know the reason why UDP-based query/response
type in host <---> access device part is required. In the I-D, a signaling
is needed between laptop and cell phone in order to identify each other's L2
address and generate the appropriated UDP/IP datagram. Isn't it sufficient
for only a simple L2 signal (like the case that host and access device
exists in the same IP node) to notify its link status? The relation between
host and access device is not changed. I think that a different rule needs
to be applied between host and access device.

The relation between a host and its access device is equivalent
to the relation between an access point and access router.
In both case, when the entities are separated, there needs to
be a protocol between two for conveying L2 information (i.e., events).

Btw, this is an abstraction.. May not apply to all architectures,
it depends on how the access device and host are connected
to each other. If the access device appears as an IP node
acting as a bridge, then this protocol applies.

> 2. In page 4, there is "A client may periodically send these multicast
Hello messages to keep track of active servers". What do you think about the
Hello message's interval (i.e., default value)?

It really depends on how dynamic and reliable the environment is.
This value must be configurable..

> For registration renewal, how is the rule applied? For example, host
issues a new registration request to refresh these active entries at
elapsing 2/3 lifetime. Is it correct?

This is also an implementation and configuration choice.
I have seen 1/2 lifetime used for similar purposes...

> 4. You said "a transport mechanism is needed to convey link-layer
triggers". Isn't it sufficient for ICMP or IPv6 extension header/Destination
option header to convey L2 triggers?

I really didn't mean defining a new transport protocol like TCP, UDP, etc...
I guess "transport" keyword can be misleading... I meant a carrier, like
defining a protocol "based on" UDP... This is what this protocol is all
about.

> 5. UDP/IP datagram is constricted to 255 TTL. However, I think if a host
moves to another AR's boundary, TTL value will decrease. What do you think
about?

This protocol is limited to nodes on the same IP subnet.
Therefore protocol messages would not normally go
beyond routers. If they do, that means there is something wrong.

Thanks Jihoon for the comments. I hope I answered your
questions.

alper

> To: "JinHyeock Choi" <[email-masked]>; "Vernon Schryver"
<[email-masked]>; <[email-masked]>
> Subject: Re: [pilc] RE: AD request / L2 Triggers Charter Statement/
Updated Internet-Draft on Fast Router Discovery

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Jun 2002 21:09:49 -0700 (PDT)

Thanks Carl for submitting this draft.
For your information there is another draft somewhat
in the same lines of thought, i.e. something that
could be considered as the problem statement for L2
Triggers work, it is at:
http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt

So we have now two problem statement drafts.

Have a happy reading.

--behcet

---

From: "Carl Williams" <[email-masked]>
Date: Thu, 27 Jun 2002 21:24:02 -0700

Hi Bechet,

    The draft we submitted describes some of the current
    discussions from the pre-BOF and wg alias.   I think
    it is a bit unique than draft-corson.  However, I think
    that a possible merge down the road would be in order.
   
    These drafts and others such as L2 Trigger requirements
    and L2 Protocol might server well as material for an
    official BOF at some point in time.

Carl

---

From: "Jihoon Lee" <[email-masked]>
Date: Sat, 29 Jun 2002 10:53:20 +0900

Hello. Alper E. Yegin.
Thank you for your kind answer.
I would like to ask additional questions.

1. You said, "this protocol is limited to nodes on the same IP subnet. Therefore protocol messages would not normally go beyond routers." 
Is this limitation necessary? In some case, L2 trigger message needs to go beyond one IP subnet. For example, old AP and new AP may be in different IP subnet. 

+------+                   +------+
 |  AR   | ------------  |  AR   |
+------+                   +------+
    |                                 |
    |                                 |
+------+                   +------+
 |  AP   |                     |  AP   |
+------+                   +------+
     |
     |
+------+
 |  MN  | ---------->
+------+

In IAPP protocol, APs in different IP subnet can exchange UDP messages. Is it necessary to limit this protocol within just one IP subnet? It may be better to relax this restriction.

2. In I-D, you indicated a carrier is meant, like defining a protocol "based on" UDP". 

Is it only for IPv4 or does this include IPv6 too? In IPv6, it may be better to use ICMP or Extension Header to carry L2 trigger. For example, in Mobile IPv4, Binding update is using UDP. But in Mobile IPv6, Binding Update is using Mobility Header. Would you explain why you choose UDP instead of ICMP or Extension Header?