Re: RE: AD request / L2 Triggers Chapter Statement

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?



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