|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Fw: "...the IPv4 TOS field should be end-to-end...."
In my opinion, NANOG may want to define itself as a collection of people and companies who endorse, deploy, support, etc. a network which is very SIMPLE, one which supports IPv4 end-to-end with no changing of the bits that historically have not been changed and no dropping of packets in the middle, until the TTL counts to 0. Note, we have to live with the changing checksum field. It seems to me that NANOG could focus on SIMPLE protocols and maximum performance. If NANOG chooses to become a group chasing the protocol-du-jour, then it seems to me that there will be another body of people needed to focus on the simple IPV4 transport, that supplies end-to-end IPv4 service, not some "re-wrote the rules" and re-wrote the bits protocol. If Karl[1] were here, he would probably refer to that as a NotWork, as opposed to a NetWork. [1] - http://www.denninger.net/ It seems to me that NANOG has to choose what it wants to be. If NANOG decides to focus on the SIMPLE IPv4 transport approach, then people might want to start testing to see which vendors conform and which do not. A simple test suite should be able to do that. Those that do not conform, should not have traffic routed to them until they do conform. Why would people continue to allow people to be connected to a NetWork if they are doing things that make it NotWork ? It seems to me it will be hard enough to make it all work, day to day, 24x7 with the SIMPLE approach. If you do not draw the line some place, then, in my opinion NANOG will cease to be what NANOG is famous for, and will gravitate to be one of many "chat rooms" on the net, lost in cyberspace. Maybe that is your fate... 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: Alan Hannan <[email protected]> To: JIM FLEMING <[email protected]> Cc: <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]> Sent: Tuesday, November 21, 2000 1:32 AM Subject: Re: Fw: "...the IPv4 TOS field should be end-to-end...." > > Jim, > > Thanks for pointing out a blinding glimpse of the obvious. > > The purpose of the RFC is to allow just that; rather, make legal the > changing of the (formerly-known-as) precedence bits. > > Having run an operational network with a large customer set, we found > in operational testing that only certain stacks (effectively only > certain macTCP versions) are actually "precedence-aware". > > This fractionally small minority obstructed our desire to implement > production observance of the precedence bits. > > The greater good of the forward movement of DSCP use is collectively > determined to be of greater importance than the needs of those > inflicted with "precedence-aware" behaviour. > > ( Additionally, the "precedence-aware" stacks can be accomodated by > strictly setting the DSCP in most all cases. ) > > Therefore, we "re-wrote the rules" by introducing the RFC to > accomodate the oversight in considerations. > > I fail to grasp the point of your diatribe, although it seems to be > that you are against any ISPs modifying the internal bits of your IP > packets. I'll assume you are comfortable w/ them modifying TTL. > > Can you concisely state for me and the group exactly what your > objection and/or problem is, please? > > -alan > > > > Thus spake JIM FLEMING ([email protected]) > on or about Tue, Nov 21, 2000 at 01:01:40AM -0600: > > > > With the advent of DiffServ, intermediate nodes may modify the > > Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header > > to indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597, > > RFC2598]. The DSCP includes the three bits formerly known as the > > precedence field. Because any modification to those three bits will > > be considered illegal by endpoints that are precedence-aware, they > > may cause failures in establishing connections, or may cause > > established connections to be reset. > > > > ----- Original Message ----- > > From: Alan Hannan <[email protected]> > > To: JIM FLEMING <[email protected]> > > Cc: Roeland Meyer <[email protected]>; 'Shawn McMahon' <[email protected]>; > > <[email protected]> > > Sent: Tuesday, November 21, 2000 12:15 AM > > Subject: Re: "...the IPv4 TOS field should be end-to-end...." > > > > > > > > > > This has been addressed in the appropriate standards bodies: > > > > > > ftp://ftp.isi.edu/in-notes/rfc2873.txt > > > > > > -alan > > > > > > Thus spake JIM FLEMING ([email protected]) > > > on or about Mon, Nov 20, 2000 at 11:33:30PM -0600: > > > > > > > > In my opinion, the IPv4 TOS field should be end-to-end.... > > > > ...clients should set it....routers should leave it alone.... > > > > > > > > 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: Roeland Meyer <[email protected]> > > > > To: 'Shawn McMahon' <[email protected]>; <[email protected]> > > > > Sent: Monday, November 20, 2000 11:29 PM > > > > Subject: RE: ISPs as content-police or method-police > > > > > > > > > > > > > > > > > > Please reference any suit regarding breach of contract. Examples > > abound. > > > > > Port filtering may be construed as a material breach when the > > expectation > > > > > is, that there is to be no port filtering. Access is access, even when > > the > > > > > customer doesn't know that they are being restricted in their access. > > That > > > > > just assures you that they will go ballistic when they find out. > > > > > > > > > > Face it guys, you KNOW that this is basically dishonest. As such, it > > is > > > > > indefensible. I would almost bet <amount> that none of the transit > > > > providers > > > > > mentions restrictions, on access, in their contracts. I would almost > > bet > > > > > <1/2 amount> that NONE of the access providers mention same in THEIR > > > > > contracts. The general expectation is for clear and open pipes. Put > > such > > > > > restiction into your contracts and you will lose customers. Don't put > > them > > > > > in and start filtering anyway and you will lose court cases...big > > ones. > > > > > > > > > > > -----Original Message----- > > > > > > From: Shawn McMahon [mailto:[email protected]] > > > > > > Sent: Monday, November 20, 2000 7:21 PM > > > > > > To: [email protected] > > > > > > Subject: Re: ISPs as content-police or method-police > > > > > > > > > > > > > > > > > > On Mon, Nov 20, 2000 at 12:03:57PM -0500, Christian Kuhtz wrote: > > > > > > > > > > > > > > What doesn't make sense in that argument is why you > > > > > > couldn't just simply > > > > > > > upsell the customer to a managed fw solution etc if that's > > > > > > the concern. > > > > > > > Educate them, and let them decide based on the education > > > > > > they received. > > > > > > > > > > > > Because it doesn't just affect them; it affects you, your customers, > > > > > > and your business. > > > > > > > > > > > > > I wouldn't be so sure, particularly because of the legal > > exposure... > > > > > > > > > > > > Does anybody have a live example of this supposed legal exposure, to > > > > > > counter all the many examples those of us who don't believe in it > > have > > > > > > given? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
|
