Michael Thomas <[EMAIL PROTECTED]> writes: > > One must ask what kind of layer violations this is intended to > > stop, and what the purpose of those layer violations is. Generally > > speaking, routers only reach in to the lower layers to determine how > > to differentiate traffic between two hosts for purposes of > > prioritization. > > UDP ports in ESP encrypted payloads. Tunnels inside > tunnels inside tunnels inside tunnels. New protocols > which may not even have abstracted ports. New Protocols > period. TCAM widths that lose to Moore's Law. > > Need I go on?
Yes, you need to go on. For the most part, I'm not sure this is going work out. As I note, we've already deployed. Windows XP and such aren't going to be obeying any of this, so the routers have to look at the contents of the packets anyway. For many of the protocols we're dealing with here (such as tunnels inside tunnels) it isn't clear there is a clean way for the mechanisms to actually extract an appropriate flow label under the new definition, and, most importantly, as I noted earlier, you can't figure out how to prioritize traffic using the flow label anyway. > > If it is intended to stop routers looking at the different layers to > > prioritize traffic, it is a failure, since the flow label tells an > > intermediate router nothing it needs to know to prioritize traffic > > other than "this is flow #N". You can't decided "hmm, interactive > > traffic -- better bump that above bulk file transfer" based on the > > flow label. At best, you can use the flow label for doing something > > like penalizing flows with non-friendly flow control > > characteristics. > > RSVP is your friend. The century that RSVP is implemented and deployed I'm sure it will be used, at least once in a while. (I don't expect our descendants to see that day, but...) Meanwhile, in practice what people tend to do on things like congested leaf routers is prioritize based on traffic type. -- Perry E. Metzger [EMAIL PROTECTED] -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
