In any case, the behaviour when you see an "unknown" flow label should be the same as when you see a zero label - apply default treatment, whatever that happens to be locally. No need to either drop the packet or rewrite the label; at that point it's just a noise field.
Brian Robert Elz wrote: > > Date: Fri, 11 Jan 2002 10:02:46 -0500 > From: "Steven M. Bellovin" <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | But dropping the packet means that flow > | labels can only be used for flows that stay within a particular flow > | label domain, > > No, you have accepted one of Margaret's arguments, taken that to its > logical conclusion, and reached absurdity, so obviously, something has > to be wrong. > > But it isn't the immutability that's wrong, it is the assumption that > different QoS mechanisms can redefine the flow label field in different > incompatible ways. > > That simply cannot be allowed to happen, or any kind of usable QoS is > even less likely to ever get deployed than the small chance there seems > to be at the minute. > > There has to be (absolutely) one fixed consistent definition for the > field, that all QoS mechanisms (now or in the future) can live with. > If anyone needs some extra data that doesn't fit, they simply have to > put that data elsewhere. If after doing that the flow label is useless > to them, then they just don't use it. > > Exactly what the one fixed definition should be, I'll leave it to others > to sort out, but there has to be exactly one - your analysis of what > happens if things are allowed to become inconsistent shows that. > > Allowing routers to change the flow label to make it "legal" doesn't > help - apart from simply making it say "unclassified" (which they could > do just as easily by putting a magic value defined by them in the DCSP) > from where would they get the information to install any other value. > > But if you can assume they can invent it from somewhere, then you need > to work out how to handle the case where my packets flow through 3 > independent ISPs, A B and C. I deal directly with A, so I can easily > provide a flow label that suits A's requirements. If B doesn't like that, > and changed it to something that fits B's requirements, what on earth > happens when the packet reaches C? At that point, C has no idea what > the flow label might mean - it could be something I put there, or it could > be something local of B's. > > That's simply impossible to support. C has to know what the value > represents (whether that then results in any special handling or not is > up to whatever agreements exist among the various parties, and what they > say - but regardless of that, if there's no way for C to interpret the > request, then agreements would be useless). > > kre -------------------------------------------------------------------- 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] --------------------------------------------------------------------
