Re: Fw: "...the IPv4 TOS field should be end-to-end...."

["JIM FLEMING" <jfleming () anet com>]

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 <alan () mindvision com>
To: JIM FLEMING <jfleming () anet com>
Cc: <vern () aciri org>; <edc () explosive net>; <alan () mindvision com>;
<xipeng () gblx net>; <nanog () merit edu>
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 (jfleming () anet com)
>  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 <alan () mindvision com>
> > To: JIM FLEMING <jfleming () anet com>
> > Cc: Roeland Meyer <rmeyer () mhsc com>; 'Shawn McMahon' <smcmahon () eiv com>;
> > <nanog () merit edu>
> > 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 (jfleming () anet com)
> > >  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 <rmeyer () mhsc com>
> > > > To: 'Shawn McMahon' <smcmahon () eiv com>; <nanog () merit edu>
> > > > 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:smcmahon () eiv com]
> > > > > > Sent: Monday, November 20, 2000 7:21 PM
> > > > > > To: nanog () merit edu
> > > > > > 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?