Hi Wes, On Wed, 28 Jul 2010 15:55:44 -0500 "George, Wes E IV [NTK]" <wesley.e.geo...@sprint.com> wrote:
> > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Tina > TSOU > Sent: Wednesday, July 28, 2010 11:57 AM > To: Aleksi Suhonen > Cc: ipv6@ietf.org > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > > On Jul 28, 2010, at 5:01 PM, Aleksi Suhonen wrote: > > > Some earlier discussion has suggested that if the label is "0", then > > it's mutable and otherwise it's immutable. > It's also fine, if people could agree on it. I'm fine with both > proposals, as long as both mutable and immutable are possible. > > And if an operator does change it, they should reset it on egress, > > and maybe hijack some other bit in the header (e.g. from DSCP?) to > > signal that the flow label has been fiddled with. This bit should of > > course also be reset at the same time as the label is reset. > > [[WEG]] I refer you to Bert Manfredi's message > http://www.ietf.org/mail-archive/web/ipv6/current/msg12042.html. The lack of > a checksum is why I'm generally resistant to the idea of preserving > immutability of this field in all or in part - while the RFC says it must be, > in practical application, a single bit error ruins that assumption. There's > no way to be sure that it's immutable within an AS, let alone across multiple > ASes, so any implementation that relies on the intermediate networks not > touching it (or worse, an implementation that "fiddles" with it and then > somehow resets it to the original value on egress) is doomed to failure. > That's why I think it could be termed a "best effort field". Links or routers that are corrupting packets within your network/AS are generally recognised fairly quickly and fixed fairly quickly, because packet corruption is unlikely to be limited to just the flow label field - it'll be impacting payloads, address fields etc. as well. So it seems to me, that within an network/AS, where traffic transport quality is usually better controlled, it could have 'best effort' acceptable uses. If best effort isn't good enough for specific applications, then you wouldn't use it. In those applications it may still be useful as a 'hint' or other use field. As an example, within your network/AS, you might use the flow field to hold a checksum, instead of carrying it in the payload. There may be a variety of applications where the quality of the local network/AS goes some way to making up for it's lack of end-to-end immutability and protection, such that the risks of using it don't outweigh the benefits gained. Thinking about the term "end-to-end" a bit further, the unstated assumption and context is "end-to-end (across the Internet)". That's the correct thing to protect against, because it is also the worst case, with the most risks. However, if the scope of "end-to-end" is reduced, e.g. "end-to-end (across a single network/AS)", the protections may not need to be as strict, allowing for other acceptable uses of this field. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
