Thank you for your comment. In my opinion, there is a difference between a "service" and a bunch of routers, which may be in service or not. If the NANOG people want to focus on the "service" of having an end-to-end network with SIMPLE IPv4 (i.e. TOS not changed in transit)**, then they should be able to point out to people which companies (deploying the service, not building routers), abide by the policy of allowing a user to insert any 8 bit value into the IPv4 TOS field, and have that same value emerge on the other side of the cloud that NANOG claims to collectively "operate". Furthermore, I would think that companies engaged in deploying the "service" would want to make sure they point out to their customers that they provide, true, end-to-end, IPv4 IP Header Transport [IPv4HT]. (let's leave TCP and UDP out of this). I would also think that companies NOT providing this service would realize that there may be no motivation for those companies that do provide the service to deal with the headaches that non-conforming companies create. In short, they should stop routing to them. Also, I would think that the sales people from companies that DO provide IPv4HT, would want to point out to the current customers of those companies who do not, that they are using a NotWork, as opposed to a NetWork. As a service to the community, NANOG can easily run some tests to see which companies provide IP4HT and which do not. I have been personally surprised that some large companies, do not even know what their global policy is. As an aside, one could consider other fields of data communications, and consider what would happen if people walked up after the fact and "re-wrote the rules". Most people are probably familiar with 8-bit PCM voice streams, imagine an end-to-end "service" where for years people were able to get a clear-channel 8-bit PCM stream. Imagine, that everything worked fine, they place a 5 in one end and a 5 comes out the other end, they place the next sample, a 67 in one end and a 67 comes out the other. Now, imagine some equipment that comes along and randomly changes the 5 to a 6 or a 4, and the 67 to a 68 or a 66. Imagine what would happen if people had built software assuming a 5 in one end comes out a 5 at the other, not a 6 or a 4. Don't you think that network operators would come together and collectively realize that they have a major mess on their hands if they continue to change the values of the data stream that the CUSTOMER was told will be delivered, end-to-end, with a best effort, and not be changed from what the customer supplied ? There are not really that many bits in an IPv4 header. In my opinion, companies should FIRST focus on making sure they have a global cloud that can reliably transport the bits in the IPv4 header from "end-to-end". I think it is up to technologists to make sure that sales people know that they need to inform their customers that they provide IPv4HT, and if that differentiates them from another company that changes the customer's bits in transit, then so be it. At some point, it seems to me that we should be able to identify a collection of vendors who provide IPv4HT. For people that want IPv4HT service, I can not imagine why they would not want to use those vendors. Why by a "service" from companies who do not provide the service ? ** [Yes, folks...I know TTL and checksum change, please do not send me private mail describing your recent "ta-da" revelation, that those fields "change".] Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: Thomas Eklund <thomas.eklund@xelerated.com> To: 'JIM FLEMING' <jfleming@anet.com>; 'Jim Bound' <bound@zk3.dec.com>; 'Alex Conta' <aconta@txc.com> Cc: 'Steve Deering' <deering@cisco.com>; 'Michael Thomas' <mat@cisco.com>; 'Francis Dupont' <Francis.Dupont@enst-bretagne.fr>; 'Jun-ichiro itojun Hagino' <itojun@iijlab.net>; 'Hesham Soliman (EPA)' <Hesham.Soliman@ericsson.com.au>; 'Metzler Jochen' <Jochen.Metzler@icn.siemens.de>; 'Ipng (E-Mail)' <ipng@sunroof.eng.sun.com>; <bound@zk3.dec.com> Sent: Tuesday, November 21, 2000 10:27 AM Subject: RE: Usage of IPv6 flow label

...

In my opinion, the IPv4 TOS should also be "e-2-e"... ...clients should set it....routers should leave it alone....

IPv4 ToS or IPv6 Traffic Class field is 8 bits and today most routers use 6 bits for them for diffserv (DSCP) and then it is per defintion PER hop behaviour and having possibility to re-write it at ingrees/egress router to your domain ..

-- thomas

-------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com --------------------------------------------------------------------