Re: RE: AD request / L2 Triggers Chapter Statement

Phil Neumiller wrote:
> 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? 

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

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

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

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




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